CN106575287A - 用于在合作性文档编辑环境中管理被建议编辑的系统和方法 - Google Patents

Abstract

文档编辑者可以在合作性文档中管理被建议编辑。所述文档编辑者可以实例化与所述合作性文档相关联的文档模型。当从第一用户接收对所述合作性文档的第一编辑建议时，基于所述第一编辑建议的类型和所述文档模型的类型，将第一建议命令与所述第一编辑建议相关联。该文档编辑者可以在所述文档模型上应用所述第一建议命令，以在所述合作性文档内呈现所述第一编辑建议。当接收针对所述第一编辑建议的接受指示时，响应于所述被接收的接受指示，所述文档模型可以利用所述第一建议命令被更新。

Description

用于在合作性文档编辑环境中管理被建议编辑的系统和方法

交叉引用

本申请要求于2014年6月24日提交的美国临时申请第62/016,259、62/016,262、62/016,280、62/016,451、62/016,456以及62/016,466号的优先权。

前述申请均通过引用明确地合并于此。

技术领域

一般地，本公开涉及电子文档，特别地，涉及用于在合作性文档编辑环境中管理被建议编辑(suggested edit)的系统和方法。

背景技术

在电子文档的开发中，经常期望让多个校对者对该电子文档的草稿提出修改和评论。例如，作者可以创建电子文档的初始草稿并将该电子文档的副本发送给多个校对者用于评论。每一个校对者可以独立地在该电子文档中提出修改或做出评论，并向作者返回该电子文档的修正版本。可以重复这些步骤，直到作者和校对者满意于一版本的电子文档为止。然而，这一过程耗时且低效。

发明内容

本文所公开的系统和方法提供了在合作性文档中管理被建议编辑的文档编辑器平台。该文档编辑器可以将与该合作性文档相关的文档模型实例化。当第一编辑建议被接收用于该合作性文档时，基于该第一编辑建议的类型和该文档模型的类型，第一建议命令与该第一编辑建议相关联。该文档编辑器可以将该第一建议命令应用于该文档模型，以在该合作性文档内呈现该第一修改建议。当接收针对该第一编辑建议的接受指示时，响应于所接收的接受指示，可以利用该第一建议命令来更新该文档模型。

附图说明

当结合附图考虑以下的详细描述时，本公开的以上特征和其他特征，包括其本质和其各种优势，将变得更为显然，在附图中：

图1是根据示范性实施例的用于提供合作性文档环境的计算机化系统100的框图。

图2A-2B提供了根据示范性实施例的示出在文档模型中管理被建议编辑的方面的示例性逻辑流程图。

图3提供了根据示范性实施例的示出文档模型的建议过滤过程的方面的示例性逻辑图。

图4A-4B示出了根据示范性实施例的示出合并被建议编辑的方面的示例性逻辑流图400。

图5示出了由校对管理器102使用的利用优先级类别以确定在文档内合并建议的顺序的方法500的流程图。

图6示出了根据示范性实施例的示出定义文档模型的省略变换的变化的方面的示例性逻辑流图600。

图7提供了根据示范性实施例的示出通知编辑者关于由合作者对合作性文档的修改的方面的示例性逻辑流图700。

图8提供了根据示范性实施例的示出将编辑转换为建议的示例性逻辑流图800。

图9是根据本公开的一个或多个实施所采用的示例性计算机系统的概略性示图。

具体实施方式

为了提供本文所描述的系统和方法的整体理解，现在将描述某些实施例，包括用于在编辑环境中管理被建议编辑的系统和方法。然而，本领域的普通技术人员将理解，本文所描述的系统和方法可以被改变和修改为适合于被解决的应用，且本文所描述的系统和方法可以在其它的适当应用中被采用，并且这些其它附加和修改将不背离其范围。通常，本文所描述的计算机化系统包括一个或多个引擎，该引擎包括处理设备或多个处理设备，比如计算机、微处理器、逻辑设备或者利用硬件、固件和软件被配置以执行本文所描述的计算机化方法中的的一个或多个其它设备或处理器。

图1是根据示范性实施例的用于提供合作性文档环境的计算机化系统100的框图。系统100包括服务器104和经由网络120连接的三个用户设备109、113和117。服务器104包括电子数据库103和校对管理器102，该校对管理器102管理对主文档106的各种版本的更新。主文档106可以存储于服务器104上的电子数据库103内，或存储于单独的存储设备中。

为了使电子文档上的合作过程更为有效，合作性文档编辑环境被提供用于集成电子文档的合作性提出的修改。在合作性文档编辑环境中，在不同用户设备处的用户可以同时访问主文档106以校对文档并提出修改。每一个用户与用户类型(比如例如编辑者、校对者、或查看者)相关联，用户类型定义了访问文档的各种版本的权限级别以及对文档的各种版本的编辑能力。如图1中所示，处于用户设备109的编辑者可以经由编辑者接口110与主文档106交互，处于用户设备113的校对者可以经由校对者接口114与主文档106交互，以及处于用户设备117的查看者可以经由查看者接口118与主文档106交互。

文档的校对者可以查看、做出被建议编辑、以及提供对文档的评论，但是可能不具有接受或拒绝任何被建议编辑的许可。校对者还可以查看由文档的其他校对者提供的被建议编辑和评论。编辑者具有比校对者更高的文档权限级别，并且可以接受或拒绝任何被建议编辑，并且还可以删除由校对者作出的任何评论。此外，编辑者通过对文档直接编辑或作出评论，还具有对文档作出直接修改的入口(access)。从编辑者接收的编辑可以被当做被接受编辑。文档的查看者具有比校对者更低的文档权限级别，并且仅可以查看不包括被建议编辑或评论的任何指示的、文档的干净的已发布版本。在示例中，当编辑者查看文档时，编辑者可以查看由多个校对者同时作出的合作性更新的动态流，这显著降低了开发该文档的时间量。以这种方式，与校对者独立提出对文档的修改的系统相比，通过允许跨越提出对文档的修改的一组用户的有效合作，本文所公开的系统和方法提供了显著优势。

应用可能需要允许修改被追踪为建议，在它们被合并入文档之前，需要它们被接受或拒绝。执行此操作需要采取以下方式表现这些修改：它们可以从该合作性文档的基本模型分离，并且允许不同修改与同一建议相关联。

图2A-2B提供了示出在文档模型中管理被建议编辑的方面的示例性逻辑流图。起始于201，文档模型可以被实例化为与合作性文档相关联。例如，文档模型可以在服务器(例如，图1中的104)处被实例化为与电子文档的主副本相关联。在202，建议性修改可以经由用户设备(例如，图1中的109)从用户接收。文档模型可以引入文档编辑模式，其中文档修改被追踪为建议，并且可以被编辑器接受/拒绝。例如，在203，文档模型能够验证用户是否具有作出被建议编辑的权限级别，例如，用户是校对者、编辑者还是查看者，并向有资格从用户设备作出该合作性文档的被建议编辑的用户提供“建议”选项。这一模型可以替换“仅评论”模型，允许具有评论入口的人们作出评论和提供建议。一般地，由编辑者作出的编辑能够由建议者执行。

在204，服务器可以基于被建议编辑，确定应用的语义。例如，建议能够以模型特定方式表现。通常，通过注释模型的哪些部分被建议插入/删除/修改来表现它们。例如，对于字符串文本模型，保留被建议插入和删除的范围。命令可以被认为是某个可寻址空间内的动作。示例包括间隔字符串或实体图、用于展示的幻灯片列表或形状集合。给定它们的可寻址空间，可以被包括在建议者之内的命令在如下的图1中被示出：

表1：示例命令

在205，建议命令能够与编辑建议相关联。为了支持建议性修改，每一个命令可以具有对应的建议命令。当在建议模式中时，并非命令的通常版本，而是命令的建议性版本被应用。从表1中所示的示例命令得到的建议命令的示例语义可以在以下的表2中被示出：

表2：示例建议命令

从以上可见，建议命令SuggestCreate能够创建对象，但还将其标记为被建议插入。这意味着正如同通常插入那样，被建议插入操作影响可寻址空间-以后的命令假定对象的存在性。不同于通常删除，SuggestDelete实际上不删除对象，但将其标记为删除。这允许原始对象被寻址和修改，直到建议被接受或拒绝。SuggestModify可以保持对象的大约一组并行(parallel)的被建议属性。注意到没有框架命令需要建议性版本。在206，该文本模型然后可以应用该建议命令以呈现编辑建议。

继续图2B，在207，在利用文档模型呈现编辑建议之后，类似于建议命令，对每一个命令，存在对应的接受和拒绝命令。因此，在208，当接收响应于编辑建议的用户反馈时，如果在209指示接受，那么在210，文档模型能够将被建议编辑转换为被接受编辑，并且在211更新文档模型。在212，基于被接受编辑的经更新文档可以向用户发布。否则，如果在209指示拒绝，那么在213，编辑建议可以从文档移除。示例接受或拒绝语义可以在以下的表3中被示出：

表3：示例接受/拒绝语义

如表3中可见，AcceptCreate可以将对象取消标记为被建议插入，这使它与被通常插入的对象相同。RejectCreate可以删除对象。类似地，AcceptDelete删除该对象，并且RejectDelete取消将其标记为被建议删除。AcceptModify接受并行属性并将它们移动到该对象的一般属性中。这推翻了一般属性，并去除了类似属性。RejectModify可以去除类似属性。

每一个建议命令具有标识(id)，以使得多个命令可以被概念性地连接在一起成为单个建议。这些id以以下的形式被保留在模型内的各处：

●当对象被标记为被建议插入或删除时，该建议具有依附其的标识。对象可以具有多个被建议插入或删除id。

●当对象的属性被建议时，它们在并行空间内被修改。该空间与id相联系(tie)，以便单个建议内的多个属性修改被一并保留。对象可以具有多个属性修改并行空间。

●当建议移动时，对象在空间中停留，并且利用新的被提出索引来注释。该索引与建议id相联系，以便多个建议id能够提出不同的移动索引。

●当建议替换时，邻近于原来对象，新的对象被插入，并且二者被注释为彼此的替换。这些替换注释将与建议id相联系。

此外，接受和拒绝建议的命令也具有id。对于存在提出同一删除或同一属性修改的多个建议的情形，该id允许用户指定哪个建议实际上被接受/拒绝。注意到对于应用目的，建议id足以识别什么被接受或拒绝。然而，可能需要全部的命令数据，比如间隔范围，以相对于这些命令来适当地变换。

以下示例提供了示例命令，对于SuggestCreate和SuggestDelete：

1.建议某文本的插入：

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

2.建议某文本的删除：

a.SuggestDeleteSpacers(id:“b”,start:10,end:20)

3.接受第一建议：

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

4.拒绝第二建议：

a.RejectDeleteSpacers(id:“b”,start:10,end:20)

在另一示例中，SuggestModify的应用可以在下表中被表述：

表4：建议性函数的示例

可以执行建议、接受和拒绝命令的反向。由于它们是通常命令，因此建议、接受和拒绝命令需要反向以支持取消这些操作。如下表中所示，因为建议创建建议且拒绝去除建议，因此建议和拒绝命令彼此反向。

表5：示例拒绝语义

然而，应用可能不具有自然的反向。这意味着可能需要新的命令来使建议反向应用。这些命令不具有反向。替代地，接受的反向可以被建模为原始命令的反向加上原始命令的建议。这里，命令数目之间的权衡可以被观察为具有这些命令的良好OT语义。下表中示出了每一个接受命令的反向语义以及如何将其建模为原始的反向加上建议。

表6：接受语义的示例反向

从上可见，通常，SuggestModify与实际属性分离地存储被提出属性。然而，如果该属性包括嵌套式可寻址空间，比如列表，这可能是存在疑议的。例如，ParagraphStyle in包含一组制表位。当某人建议制表位的插入(或删除)时，出于同一原因，可能需要与一般性创建/删除操作相同的行为。因此，建议制表位的插入操作需要将其插入实际列表并使其为被插入。建议制表位的删除操作需要将其标记为删除。因此，仅当它不在嵌套式可寻址空间之内时，应用SuggestModify可以应用并行空间内的属性。否则，它使用整体语义。

表7：示例-制表位

与所有命令类似，经由编辑系统在客户端创建建议命令。该集成的目的之一是为了使单独的编辑不知道建议。这有助于使支持新特征的建议性修改的开销最小。基本方法是采用将被通常编辑应用的每一个命令，生成命令的建议版本并替代地应用该建议版本。然而，这暴露了以下问题：建议命令的语义不等同于通常命令的语义。例如，SuggestDelete实际上不删除对象。因此，编辑不能依赖于应用生成ModelState的某些改变的命令。为解决这一问题，可以制作原始ModelState的副本，并且通常编辑函数可以被应用于该副本。这可以提供由编辑关于ModelState如何改变的任何假定将是正确的。那么，原来被应用的命令可以被采用，并生成它们的每一个的建议版本。然而，由于不同的语义，基于之前的建议命令，可以调整每一个建议命令。例如，由DragDropEdit建议生成的命令可以包括：

1.DeleteSpacers(5,10)

2.InsertSpacers“hello”@50

这些命令的建议版本可以包括:

1.SuggestDeleteSpacers(5,10)

2.SuggestInsertSpacers“hello”@56

为了生成这些命令的被建议版本，可以执行以下操作:

1.从DeleteSpacers(5,10)生成SuggestDeleteSpacers(5,10)。

2.从SuggestDeleteSpacers生成适合的变换命令。

3.从InsertSpacers“hello”@50生成SuggestInsertSpacers“hello”@50。

4.相对于变换命令，变换SuggestInsertSpacers，得到SuggestInsertSpacers“hello”@56.

在一种实施中，建议编辑文档环境所涉及的示例对象类可以采用类似于以下伪代码段的形式：

/**提供建议编辑。*/

class SuggestEditProvider(editProvider){

Edit provideEdit(context){

return new SuggestEdit(context,this.editProvider_.provide(context.copy())

}

boolean canApply(context){

return this.editProvider_.canApply(context)

}

}

/**将给定的编辑应用为建议。*/

class SuggestEdit(context,edit){

void applyInternal(args){

var result＝this.edit_.apply(args)；

var id＝String(Math.random())；//Some random string.

var transformCommands＝[]；

for each command in result.getCommands(){

var suggestedCommand＝this.commandSuggestor_.getSuggestedCommand(command,id)；

var pair＝this.transformer_.transformBoth([suggestedCommand],transformCommands)；

transformCommands＝pair.getCommands()；

suggestedCommand＝pair.getCommandsToWin()；

transformCommands.push(

this.commandSuggestor_.getTransformSuggestCommand(suggestedComma nd)；

this.applyCommand(suggestedCommand)；

}}

}

/**从通常命令创建建议命令。*/

interface CommandSuggestor{

/**利用给定的建议id，获得给定命令的对应建议命令。这将用于以上示例中的步骤(1)和(3)。*/

Command getSuggestCommand(command,id,model)

/**给定建议命令，返回将被使用以变换同一编辑内的以后建议的命令。如被getSuggestCommand返回的，该命令将解释命令和建议命令之间的不同语义。这将用于以上示例的步骤(2)。*/

Command getTransformSuggestCommand(suggestCommand)

接受和拒绝建议还经由以下编辑被执行：AcceptEdit和RejectEdit。这些编辑可以仅由编辑者执行。当从建议评论选择接受/拒绝时，它们被触发。向编辑给出接受/拒绝的建议id，然后它将检查模型以确定哪些修改与该id相联系。适合的拒绝/接受命令然后可以被应用于这些修改。注意到，因为这取决于检查该模型以及生成接受和拒绝命令，将不存在这些编辑的通用实施。建议性接受或拒绝所涉及的示例对象类可以采用类似于以下的伪代码段的形式：

在一种实施中，建议者可以发布SuggestDelete而非通常Delete，以使得对象将被标记用于删除，而不是实际上被删除。然而，如果是被同一用户在最初建议的对象，那么允许他们删除该对象。例如，如果用户建议插入“teh cat”，那么他们可以进入并修改其笔误。这通过基于当前上下文从getSuggestedCommand返回适当的命令而完成。为了允许更为严格的语义，单独的删除命令可以被创建，以使建议者发布并然后使用验证，以确保他们不能删除任意对象。

在一种实施中，与文档相关联的访问控制列表(ACL)可以被检查用于建议。例如，评论角色下的用户已具有将命令应用于模型的能力，以使得他们可以应用追踪其评论的位置的命令。然而，经由CommandPermissionChecker接口，存在针对可以被应用的命令的限制。利用建议性修改，维持该检查应当是简单的，因为存在建议者可以发布的命令的特定集合：

·建议命令(Suggestion command)，因此他们可以做出建议。

·拒绝命令(Rejects command)，因此他们可以取消建议(并可能因此他们可以拒绝他们自己的编辑)。

·用于在建议内删除的特殊删除命令。

·MultiCommands和ReverseCommand(仅包括其它被允许的命令)

·NullCommand。

这将防止建议者对文档作出任何实际修改。然而，可以设想更为严格的ACL检查机制，其中建议者可以被防止影响彼此的建议。这一更为严格的检查当前未被执行用于评论-允许评论者应用用于锚定评论的命令，而不管谁实际上拥有该评论。执行这一更为严格的检查将是复杂的，因为它将需要了解谁拥有每一个建议id，该建议id不被存储为该文档模型的一部分。相反，可以依赖这些命令未被UI发布，并且可以基于角色而非个体来维持ACL检查。

来自不同用户、账户和/或建议id的建议可以被合并。当处于建议模式中时，不是所有编辑生成具有新的建议id的命令。例如，在多次编辑中输入句子应当生成单个建议。这些被称为被合并建议。由于建议必须被批量地接受或拒绝，所以合并确定了该粒度。示例建议合并器可以在下列示例中被表述：

1.在建议模式中输入字符:

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

2.输入另一字符:

a.SuggestInsertSpacers(id:“a”,index:6,spacers:“i”)

i.注意到id是相同的。两次插入操作现在是同一建议的一部分。

3.接受该建议:

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

4.或拒绝该建议:

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

在应用命令之前，可以检查该模型以确定该命令将与哪个建议(如果存在)合并。如果编辑中的所有命令得到由当前用户拥有的建议id，那么可以使用这些建议id。否则，可以创建新的建议id。通过以这种方式检查每一个id，比如拖/放和发现的情形可以被跨越建议来替换和支持。以下示例表述了合并过程：

表8：示例性经合并建议

这种方法的问题在于由于原始编辑被应用于ModelState的副本，所以它需要计算经合并的建议数据。在应用每一个未打开的命令之前，经合并的建议数据被计算，例如反向。如同被取消的命令那样，经合并的建议数据还将需要从原始编辑返回。实施用于反向的类似模式的机制可以被采用以计算并返回经合并的建议数据。例如，命令预处理器可以用于建议合并器，并且该预处理器还可以被适配为用于反向。

建议文档模型的另一示例实施是处理合成建议。合成建议是在其它建议内被创建的建议。例如，一个用户提出插入句子并且一个不同用户提出在该句子内插入单词。从编辑者模型的视角看，合成建议看起来就像两个通常建议：具有两个独立、唯一的建议id。如果不存在用于合成的特殊UI，那么这些建议将仅仅作为评论中两个不同的建议展现，但是作为合作性文档中的重叠区域，更像当前的重叠评论。编辑者将能够独立于最外侧的建议来接受最内部的建议。这就如同好像编辑者刚才继续执行并自己做出修改的行为一样。当特殊的UI被用于合成建议时，建议id之间的关系可以被存储于不同位置。例如，当前的UI提出了在单个评论内显示合成建议，因此该关系可以被存储于评论中。

为了确定被建议编辑是否应当与另一编辑合成，可以使用类似于以上确定合并的机制。给定针对每一个命令的一组建议id，可以使用类似的启发式方法：如果所有id相同，且该建议不由当前用户拥有，那么特定的建议id可以被合成。

建议文档模型的另一示例实施是处理替代建议。替代是彼此相冲突的建议。例如，如果一个用户提出删除句子，而另一用户提出在该句子内插入单词。不提供针对替代的特殊存储。如果希望针对替代建议的特殊UI，那么通过检查该模型，可以在客户侧检测替代。

文档模型可以向用户提供呈现建议的UI，例如，“查看”模式。在“查看”模式下的文档模型可以读取模型建议的状态并适当地渲染。例如，它可以确定某些间隔是被建议插入，并以做出该建议的用户的合作者颜色渲染它们。替代地，它可以确定某些间隔是被建议删除，并以删除线和利用适当颜色来渲染它们。

建议可以在评论中使数据相关联，并且将针对每一个建议显示评论。评论将存储建议id的被分隔的以下基本数据：

1.做出该建议的用户，

2.建议时间戳，

3.解释建议是什么的一些元数据，

4.建议已被接受还是拒绝。

用户被允许在建议上评论，就像在通常评论上评论。此外，建议将具有允许编辑者接受/拒绝它们的控制。当发生时，评论线程将被注释，非常像关闭和重新打开评论。建议评论将包括解释该建议之前行为的一些文本。这将从元数据得到。元数据将被结构化并是应用特定的，尽管一些元数据可能是通用的。潜在的元数据的示例可以采用类似于下述的形式：

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

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

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

可以存储另外的数据以支持合成建议。拷贝和粘贴对评论数据发生的行为具有另外的考虑。

建议文档模型的另一示例实施是编辑元数据。为了生成建议元数据，可以唤醒EditMetadata函数，这已服务于用于描述可访问性的编辑的这一目的。EditMetadata给出了关于该编辑之前的确切行为的细节。可以采用每个编辑的类，它采用了EditMetadata并生成了适当的评论元数据。

经由文档模型，可以执行建议中的通常编辑。编辑模式下的用户被允许影响任何内容，包括建议。当编辑者对建议做出修改时，修改被立即提交——它并非合成或被创建为建议。为了保持对谁建议了哪些内容的作者身份追踪，可以利用解释编辑者之前做过什么的一些文本来注释评论。这可以通过创建编辑的元数据并将其附加于该建议的评论线程来执行。

建议文档模型的另一示例实施是过滤建议。图3提供了示出文档模型的建议过滤过程的方面的示例性逻辑流图。

文档模型O 301可以提供编辑者可以过滤建议的模式。这些过滤器可以是按照用户或建议类型(插入、样式等)。为了允许可以支持哪些确切的过滤器的灵活性，通过应用命令的任意集合且然后当命令被来回传送时变换客户端和服务器命令，可以允许过滤。为了创建过滤器，命令C 302可以应用于模型O 301。这得到了新的模型M 303，该模型可以用于客户端查看和控制器，且可以不管过滤而允许查看和控制器逻辑维持相同。

当创建过滤器命令C 302时，还可以创建反向I(C)304。此外，两个模型301和303可以被维持：在过滤之前的原始模型301，以及在过滤后的新模型303。当变换时，这两个模型可以有助于创建适当的反向。

过滤算法可以以类似于下述的方式(在图3(a)中示出)工作：

1.生成命令过滤器命令C 302，

2.经由通常反向，创建过滤器反向命令I(C)304，

3.复制模型，保持原件O 301和副本M 303，该副本将为新模型，

4.向新模型M 303应用命令C 302。

由客户端控制器生成的任何命令可以直接应用于M。为了向服务器发送这些命令，它们需要相对于I(C)被变换。在一个示例中，全部算法可以如下执行(在图3(b)中被示出)。

1.向模型M 303应用命令X 305。这得到新模型M’307。

2.相对于I(C)304变换X 305以得到X’309和I(C)’310。

3.向原始模型O 301应用X’309。这得到新的原始模型O 312。

4.向服务器发送X’309，

5.现在，新的过滤器反向命令是I(C)’310。

6.通过反向I(C)’310，生成新的过滤器命令。

类似地，从服务器接收的任何命令可以被直接应用于O 301。为了向M303应用这些客户，它们可以相对于C 302被变换。在一个示例中，全部算法可以如下执行(在图3(c)中被示出)。

1.向原始模型O 301应用命令X 305。这得到新的原始模型O’312。

2.相对于C 302变换X 305以得到X’309和C’315。

3.向模型M 303应用X’309。这得到新模型M’307。

4.现在，新的过滤器命令是C’315。

5.通过对C’315反向，生成新的过滤器反向命令。

为了取消过滤该建议，I(C)304可以应用于模型M 303，这使得该模型现在与原始模型O 301等价。注意到并非应用反向，而是模型M 303可以利用原始模型O 301来替换。这意味着可以不需要应用I(C)304，并且因此可以使用省略命令，而非反向。通过这种方式，可以不向变换层给出原始模型的入口。然而，由于原始模型可以用于取消过滤，所以它可以被维持是最新的。

建议文档模型的另一示例实施是实施服务器改变。建议仅对于编辑模式或评论模式下的用户是可见的。查看、预览和发布模式不可以显示建议。这可能需要类似于在服务器侧过滤的逻辑。服务器可以知道如何生成具有被剥离建议的模型，以及何时应当使用该模型而非使用通常模型。建议可以被剥离的示例包含：

1.查看、预览和发布模式，

2.输出，

3.可加索引的文本和缩略图。

注意到对于以上的部分示例，比如输出和可加索引的文本，取决于访问级别，可以实施不同的逻辑以防止丢失功能。

通过利用被建议插入id来标记文本的范围来表示被建议插入。段落插入被类似地表现-换行标记被标记用于插入。

以下是以可扩展标记语言(XML)格式插入“hello”作为被追踪修改的示例伪代码段。

<w:ins w:id＝"0"w:author＝"AUTHOR"w:date＝"2013-09-12T10:58:00Z">

<w:r>

<w:t>hello</w:t>

</w:r>

</w:ins>

标签w:ins被用于指示它的内容被追踪用于插入。该标签包含修改的id(w:id)、作者(w:author)以及日期(w:data)。在以上的示例中，插入包含具有“hello”作为其文本(w:t)的文本运行(w:r)。以下是以XML格式在“hello”之后插入换行作为被追踪修改的示例伪代码段：

<w:p w:rsidR＝"009F5AAA"w:rsidRDefault＝"009F5AAA"

w:rsidP＝"009F5AAA">

<w:pPr>

<w:rPr>

<w:ins w:id＝"0"w:author＝"AUTHOR"w:date＝"2013-09-12T10:58:00Z">

</w:rPr>

</w:pPr>

<w:r>

<w:t>hello</w:t>

</w:r>

</w:p>

使用没有内容的标签w:ins来指示换行被追踪用于插入。该标签包含修改的id(w:id)、作者(w:author)以及日期(w:data)。

建议文档模型的另一示例实施是处理文本性删除。通过利用被建议删除id标记文本的范围来表现被建议删除。段落删除被类似地表现-换行标记被标记用于删除。

以下是以XML格式将“hello”标记为被追踪删除的示例伪代码段。

<w:del w:id＝"1"w:author＝"AUTHOR"w:date＝"2013-09-12T10:58:00Z">

<w:r w:rsidDel＝"00996D0B">

<w:delText>hello</w:delText>

</w:r>

</w:del>

标签w:del用于指示它的内容被追踪用于删除。该标签包含修改的id(w:id)、作者(w:author)以及日期(w:data)。在以上的示例中，插入包含具有“hello”作为其文本(w:delText)的文本运行(w:r)。以下是以XML格式在“hello”之后标记换行作为被追踪删除的示例伪代码段：

<w:p w:rsidR＝"009F5AAA"w:rsidDel＝"00635749"w:rsidRDefault＝"00635749"w:rsidP＝"009F5AAA">

<w:pPr>

<w:rPr>

<w:del w:id＝"1"w:author＝"AUTHOR"w:date＝"2013-09-12T10:58:00Z"/>

</w:rPr>

</w:pPr>

<w:r>

<w:t>Deleted</w:t>

</w:r>

</w:p>

使用没有内容的标签w:idel来指示换行被追踪用于删除。该标签包含修改的id(w:id)、作者(w:author)以及日期(w:data)。

经由从建议id到被建议属性的映射，来表现被建议文本样式。该映射被应用于文本的范围。以下是以XML格式对“hello”应用“粗体”作为被追踪修改的示例伪代码段。该单词已被斜体化。

<w:r w:rsidR＝"006B2B93"w:rsidRPr＝"006B2B93">

<w:rPr>

<w:b/>

<w:i/>

<w:rPrChange w:id＝"2"w:author＝"AUTHOR"

w:date＝"2013-09-12T15:14:00Z">

<w:rPr>

<w:i/>

</w:rPr>

</w:rPrChange>

</w:rPr>

<w:t>hello</w:t>

</w:r>

存在具有运行属性标签(w:rPr)和某文本(w:t)的文本运行(text run)(w:r)。运行属性包含当前属性，该当前属性包括被追踪修改：粗体(w:b)和斜体(w:i)。它还包含运行属性修改标签(w:rPrChange)，该标签包含在应用被追踪样式之前的属性，该属性仅为斜体(w:i)。属性修改标签还包含该修改的id(w:id)、作者(w:author)以及日期(w:data)。

经由从建议id到被建议的属性的映射，来表现被建议段落样式。该映射被应用于段落的换行。以下是以XML格式将“center”作为被追踪修改应用到包含“hello”的段落的示例伪代码段。

<w:p w:rsidR＝"00ED223B"w:rsidRDefault＝"001243D1"w:rsidP＝"001E67D7">

<w:pPr>

<w:spacing w:line＝"240"w:lineRule＝"auto"/>

<w:jc w:val＝"center"/>

<w:pPrChange w:id＝"4"w:author＝"AUTHOR"

w:date＝"2013-09-13T16:39:00Z">

<w:pPr>

<w:spacing w:line＝"240"w:lineRule＝"auto"/>

</w:pPr>

</w:pPrChange>

</w:pPr>

<w:r>

<w:t>hello</w:t>

</w:r>

</w:p>

存在具有段落属性标签(w:pPr)和文本运行(w:r)的段落运行(w:p)。段落属性包含当前属性，该当前属性包括被追踪修改：行间距(w:spacing)和对齐(w:jc)。它还包含运行属性修改标签(w:pPrChange)，该标签包含在应用被追踪样式之前的属性，该属性仅为行间距(w:spacing)。属性修改标签还包含该修改的id(w:id)、作者(w:author)以及日期(w:data)。

经由从建议id到被建议的属性的映射，来表现被建议列表样式。该映射被应用于段落的换行。还经由从建议id到属性的映射，来表现影响列表实体的被建议修改。该映射被应用于列表实体。

以下是以XML格式将包含“hello”的段落添加到列表作为被追踪修改的示例伪代码段。

<w:p w:rsidR＝"006F3E3C"w:rsidRDefault＝"006F3E3C"w:rsidP＝"006F3E3C">

<w:pPr>

<w:pStyle w:val＝"ListParagraph"/>

<w:numPr>

<w:ilvl w:val＝"0"/>

<w:numId w:val＝"3"/>

</w:numPr>

<w:pPrChange w:id＝"6"w:author＝"AUTHOR"

w:date＝"2013-09-13T16:39:00Z">

<w:pPr/>

</w:pPrChange>

</w:pPr>

<w:r>

<w:t>five</w:t>

</w:r>

</w:p>

存在具有段落属性标签(w:pPr)和文本运行(w:r)的段落运行(w:p)。段落属性包含当前属性，该属性包括被追踪修改：应用被命名为样式(w:pStyle)的“ListParagraph”，并将该段落添加至处于嵌套层“0”(w:ilv1)的列表id“3”(w:numid)。它还包含运行属性修改标签(w:pPrChange)，该标签包含在应用被追踪样式之前的属性，该属性为空(w:pPr/)。属性修改标签还包含该修改的id(w:id)、作者(w:author)以及日期(w:data)。

本文所描述的另一实施例包括在合作性被编辑文档内合并被建议编辑的系统和方法。文档编辑器可以允许用户作出作为建议的编辑，该建议可以被追踪，并且在被并入该文档之前被接受或拒绝。这些建议作为对该文档的可以被独立地接受或拒绝的不同修改而存在。当用户作出单独行为以编辑文档时，比如输入字符，不期望这些行为的每一个单独地生成独立建议。特别地，当文档的校对者打开文档并创建对文档的被建议修改时，不是所有编辑应当生成具有新的建议标识符的命令。例如，在多次编辑中输入句子应当生成单个建议。因为从多次编辑或变化得到单个建议，所以这些被称为被合并建议。由于建议必须被批量地接受或拒绝，所以合并确定了建议的粒度。

本公开的第六示例性实施例的系统和方法确定对模型的当前修改是否应当与现有建议合并，或者这样的修改是否应当创建新建议。本公开的系统和方法具有充分的一般性，从而对文档模型的任何修改或修改的集合均可良好运行。现有系统未考虑整个文档模型，并且不保持一致性和用户意图。

图4A-4B示出了表示合并被建议编辑的方面的示例性逻辑流图400。方法在401开始，响应于所接收的编辑建议(例如，图2A中的202)，服务器或用户设备处的文档编辑器可以确定是否将所接收的编辑建议与现有的编辑建议合并，或者创建新的编辑建议。文档编辑器可以确定与编辑建议相关联的一个或多个变化。例如，经由一系列渐进式原子变化，可以描述对文档模型的修改。在文档编辑环境中，比如文本编辑器，变化可以包括插入字符、删除字符、应用样式、或可以对文本文档作出的任何其它类型的修改。对文档的单个被建议编辑可以导致被应用于模型的多个变化。

例如，被建议编辑可以包括具有多个字符插入的添加单词或词组。在另一示例中，被建议编辑可以包括利用不同词组替换现有词组。这样的被建议编辑将包括多个字符删除和多个字符插入。在又另一个示例中，被建议编辑可以包括插入一个或多个字符，并对被插入字符改变样式。在每一个示例中，被插入编辑包括对文档的多个变化。当变化被依序接收时，通常期望确定当前变化是否应当与之前变化合并为单个编辑的一部分，或者当前变化是否应当被特征化为新编辑的一部分。

本文提供了用于确定是否将对文档的当前改变与现有的被建议编辑合并，或者是否基于该当前改变来生成新的被建议编辑的系统和方法。文档编辑器具有基于用户动作和该文档编辑器的当前状态来确定向该文档应用哪些变化的逻辑。

在402，文档编辑器然后可以定义针对每一个变化的函数。函数确定变化可以与哪些建议合并。该函数可以被定义用于编辑应用中的特定变化和文档模型。作为示例，在文档编辑器中，插入字符的变化可以与在该被插入文本的之前、之后或周围产生的任何被建议文本合并。

此外，函数可以确定变化的合并优先级。在示例中，变化按照优先级顺序排序，以使得在较小的修改之前可以考虑对文档的较大的修改。例如，如果被建议编辑包括插入文本和应用样式，则与样式应用的位置相比，插入的位置更可能成为合并的候选。在这种情形下，插入变化可以比样式应用变化更为优先。

在403，当变化被应用于模型时，运行函数以识别任何潜在的合并建议和优先级的列表。在405，文档模型然后可以确定是否需要从该列表过滤任何变化。例如，在406，不被当前用户拥有的任何建议可以被移除或从列表过滤。以这种方式过滤列表确保由当前用户作出的建议不会与由其他用户作出的建议合并，并替代地创建由当前用户拥有的新建议。替代地，函数可以包括一个或多个过滤器，以使得列表中由该函数识别的任何潜在的合并建议优先级仅与当前用户相关联，而不是与其它用户相关联。

通常，在确定是否合并被建议编辑时，插入和删除通常文本具有最高的优先级。可以根据以上的启发式方法来定义与插入和删除文本合并的建议。具体地，插入返回与在插入位置之前或之后的插入或删除合并的建议。删除返回与在删除范围之前、之后或内部的任何插入操作或删除合并的建议。与样式相关的修改具有次优先级。例如，这包括文本和段落样式、对列表和链接的修改。仅当修改范围被全部包含在删除或插入内时才合并这些编辑。如果范围相同或者如果在其它样式内部且影响同一属性，则它们还与其它被建议样式合并。次文本的删除具有次优先级，并且与同一文本的其它删除合并。次文本是文档主体以外的文本，它通常与该文档相关，例如，比如头部、页脚、脚注。次文本的插入具有最低优先级并且不返回合并建议。该文本将总是生成新的建议(比如在头部和页脚的情形下)，或者它与主(primary)文本(比如脚注)相关，因此将使用与启发式方法合并的主文本。

在确定如何合并被建议编辑时，示例性实施例的方法可以包括定义与合并相关联的优先级的类别的框架，该合并落入该类别之内。每一个建议可以被分配合并建议标识符，该合并建议标识符识别被建议行为以及被建议修改的优先级类别。取决于被建议编辑被合并所依的优先级，这些优先级类别被分为主、次和中性优先级合并的示例类别。

在示例中，主优先级类别包括比如非章节间隔的插入和删除的建议。次优先级类别建议包括向文档文本应用不同的样式、关联、更新或删除实体；或删除章节。中性优先级类别建议包括插入章节、增加实体和各种其它建议命令。

继续图4B，在于407处确定被过滤的列表之后，在408，检查最高现有优先级的所有潜在的合并建议，以确定在410处，是否应当发生合并。如果该优先级处的所有变化具有相匹配的建议，那么发生合并。否则，不应当发生合并，且在411，创建新建议。

如果合并发生，那么在415，本文所描述的系统和方法确定过滤列表的可能建议中的哪个建议应当用于合并。多种方式可以确定哪个建议应当用于合并，并且本文所描述的示例仅用于表述性示例。

在一个示例中，更为常见的建议可以被优选为用于合并。一种特定方式是优选更为常见的建议。若干步骤可以用于实施这一点。首先，创建指示每个建议多久发生的直方图。其次，从最常见到最不常见来考虑变化，并且可以与特定建议合并的任何变化可以被使用。第三，对于不具有潜在的合并建议的任何变化，那么使用具有最高优先级的最通常发生的建议。当确定使用哪个建议来合并时，在416，编辑建议可以被合并。

如本文所描述的，本公开的目的之一是定义跨越不同编辑来合并建议的机制，以及当被建议编辑应用于文档模型时确定收集该合并数据的机制。以下的示例提供了当两个字符被输入时系统的实施，并且该系统确定该两个字符一并属于同一建议：

1.在建议模式下输入字符:

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

2.输入另一字符:

a.SuggestInsertSpacers(id:“a”,index:6,spacers:“i”)

i.注意到id相同。两次插入现在是同一建议的一部分。

3.接受该建议:

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

4.或拒绝该建议:

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

在应用命令之前，文档模型可以确定该命令应当与哪个建议(如果存在的话)合并(例如，图4B的415)。如果编辑中的所有命令与由当前用户拥有的建议标识符相关联，那么可以使用这些建议标识符。否则，可以生成和使用新的建议标识符。通过按每个标识符执行这一操作，包括剪切/粘贴或查找/替换的修改可以被有效地实施。

在另一示例中，基于被分配给被建议编辑的优先级类别，当在以下情形时，基本的启发式方法包括完成建议的合并：在插入之后/之前/内部输入、在删除之后/之前/内部输入、在具有被建议文本样式的换行之前输入、在删除之前/之后/内部/周围删除、在插入之前/之后/内部/周围删除、在删除内部输入、在插入之前/之后/内部输入、在插入内部改变样式、在删除内部改变样式、改变应用于与另一样式完全相同的区间的样式、改变其它样式内部的样式、如果影响了同一属性，或者变更了应用于在被建议插入之后的换行的文本样式。当在以下情形时，建议不被合并：在样式之后/之前/内部输入、在样式之前/之后/内部/周围删除、在删除之前/之后输入、在替换之前/之后输入、在插入之前/之后改变样式、在删除之前/之后改变样式、在重叠插入改变样式、在重叠删除改变样式、或在不处于同一范围的其它样式的内部、之前、之后或与之重叠处改变样式。

对换行周围和文本样式的考虑存在两种特殊情形：在具有被建议文本样式的换行之前输入，以及应用于被建议插入之后的换行的文本样式。这些特殊情形以类似于以上所描述的方式实施：插入合并逻辑检查该插入是否在具有被建议文本样式的换行符之前，并且样式合并逻辑检查该样式是否应用于被建议插入操作之后的换行。这些情形生成几个问题的解决方案。在一个示例中，利用未建议的换行开始空段落不成问题。在第二示例中，在建议编辑的同时点击“粗体”向换行应用被建议样式。在第三示例中，输入字符在换行之前插入字符。插入字符的建议与之前的建议合并。

图5示出了由校对管理器102使用的利用优先级类别以确定在文档内合并建议的顺序的方法500的流程图。方法包括以下步骤：确定是否存在任何主类别建议(确定块502)，确定是否存在任何次类别ID命令(确定块506)，并基于这些结果，适当地合并被建议编辑。如果存在主优先级类别建议，这些合并被执行(步骤504)。如果存在次优先级类别合并，它们被执行(步骤508)。替代地，如果不存在次优先级类别的建议，不进行进一步的合并(步骤510)。

合并包括插入的被建议编辑根据若干规则发生。在一种实施中，在评论模式下按下ENTER键插入针对每一个换行的单独评论。输入多个段落，得到涵盖被建议段落的被合并编辑。

在一些情形下，多个用户可以建议对文本的各种编辑，包括相冲突的建议。在建议相冲突的情形下，建议应当被合并为单个建议。在一些实施中，编辑者可以具有取消、接受或拒绝被建议的相冲突编辑的能力，并且使用这些能力可以使得所有的相冲突建议消失。

对段落样式的被建议编辑，被处理为分离于对该段落文本的编辑。在一个示例中，修改被建议的标题不改变段落实体的样式。在另一个示例中，合并编辑系统被配备以处理其中“添加实体”的建议从来不合并的问题。在第三示例中，修改被建议链接不总是起作用。

一般地，根据一系列原则来完成确定是否合并被建议编辑的方法。单个动作总是被显示为单个建议。对于以下操作，执行合并：在插入内完全的样式改变、同一实体被选定时的样式改变、输入被建议文本的连续范围、在被插入文本内部的输入、以及对于可以合并的对象，包括内联的图片、公式、自动图文集、脚注、以及书签。在表的一些插入中，内容的被定位图片、头部、页脚以及表不可以与其它编辑合并。

本文所描述的方法具有若干优势。首先，由特定用户做出的建议可以仅与由同一用户做出的建议合并。其次，单个用户动作将绝不会创建多于一个建议。第三，在编辑内的变换之间维持一致性。换言之，所有变化或者与现有建议合并或者被分配给新建议。第四，当单个编辑影响了多个现有建议时，维持一致性。通过支持每一个变化优选与其合并的建议，影响多个建议的编辑让它们的变化组分与它们分别影响的建议合并。

本文所描述的另一个实施例包括应用于文档模型的投射。客户系统或用户设备可以具有应用于它们的文档模型的投射。例如，投射可以用于剥离某些类型的内容或使文档的某些部分匿名。可以依据应用于该模型的变化来描述投射。当投射应用于模型时，生成变化，当应用该变化时，生成该投射下的模型。例如，剥离表格的投射将生成针对每一个表格的删除表格变化，这得到没有表格的模型。

为了向其模型在投射之下的合作者广播变化，该变化应当相对于描述该投射的变化来变换。例如，向具有一些被过滤文本的模型广播插入文本变化，需要相对于与被滤除的文本相对应的删除文本变化来变换插入文本。

另外，当在投射下广播时，应当完全省略一些变化。例如，如果投射从文档移除表格，那么创建新表格的变化不应当被发送给具有该投射的客户端。对于单独的变化，实施是简单的。特别地，省略的这些变化应当被识别用于某些投射，并且被识别的变化不应当被广播。

然而，由于以后的变化可以依赖于或假定被省略变化的存在，所以省略某些变化可能影响以后的变化。例如，如果广播两个变化([例如，在索引100处插入文本，在索引200处插入文本])，那么第二个插入操作可以假定已完成第一个插入操作。以这种方式，如果省略第一个插入操作，且不知情地广播第二个插入操作，那么被广播的插入操作处于错误的索引。

为解决这一问题，定义省略变换变化。省略变换变化是这样的变化，对于该类变化，以后的变化需要被变换以解释由于省略而造成的不同语义。在以上的示例中，[在100处插入文本]的省略变换变化是[在100处删除文本]。通过相对于删除变化来变换[在200处插入文本]，[在200处插入文本]被向回移动并将处于正确的索引。通过这种方式，省略变换变化允许以后的变化考虑文档的投射，并因此相应地被适当调整。

图6示出了表述定义文档模型的省略转换变化的方面的示例性逻辑流图600。该技术可以被总结为如下步骤。

在601，初始化变化的空集R。

在602，生成用于将投射应用于当前模型的变化的集合S。

针对要广播的变化的集合中的每一个变化M:

在603，通过相对于S变换M，生成M’和S’。

在605，如果M’由于投射应当被省略：

则在606，生成针对C’的省略变换变化O。

在607，将O添加至S’。

否则：

在608，将C’添加至R。

在609，将S’设置为新的S。

R是结果。

作为总结，当定义投射时，可以定义：(1)给定模型，其中哪些变化应用投射；以及(2)应当省略哪些变化和针对这些变化的省略变换变化是什么。一旦这些被定义，那么本公开的系统和方法可以用于合作性地广播投射下的变化。

以这种方式来解决问题存在一些优势。首先，本公开允许投射被完全应用于服务器侧，允许强制客户端位于某些投射之下。其次，本公开利用了在实时的合作应用中现有的操作性转换语义。

在示例中，投射被应用于从查看者可获得的文档的版本过滤被建议修改。本公开使得对该文档的修改能够被适当地应用，以使得该文档的最新版本向该文档的查看者呈现。为了从向查看者示出的文档的“查看模式”移除被建议修改和评论的显示，实施文档的查看模式的应用引擎可以涉及以下步骤的任何组合。

投射的概念可以应用于文档模型。表述投射的对象类的示例伪代码段可以采取类似于以下的形式：

取决于建议是否应当总是被过滤，将利用适当的投射来替换用法(usage)。

可以使用基于访问控制列表(ACL)的过滤。基于用户是否具有对文档的查看或编辑入口，建议的一些用法将需要上下文的过滤。为了实现这一点，可以使用代理(factory)来构造权限。示出基于ACL过滤的对象类的示例伪代码段可以采用类似于以下的形式：

基于AccessLevel的投射:

针对编辑者和校对者(评论者)，代理将返回Projection.FULL，以及针对查看者，将返回Projection.WITHOUT_SUGGESTIONS。此外，缺省值可以被投射用于Projection，Projection将使用代理以针对用户的AccessLevel返回正确的投射。

在另一实施例中，可以实施改变过滤。在一些实施中，基于AccessLevel的根据上下文来过滤模型可能是不够的。载入或传送修改的用法可能也需要被过滤。以下步骤可以用于过滤针对查看者的命令：

1.初始化命令的空集R。

2.生成用于过滤当前模型建议的命令集合S。

3.针对修改中的每一个命令C：

a.通过相对于S变换C，生成C’和S’。

b.如果C’是建议命令：

i.生成C’的省略命令O。

ii.将O加到S’。

c.否则：

i.将C’加到R。

d.将S’设置为新的S。

4.R是结果。

在一些实施中，可以使用以下方法来生成过滤器命令(可以是示出以上步骤2的示例伪代码段)。

Projection.FULL的实施总是可以返回空列表。不支持建议的实施，比如Projection.WITHOUT_SUGGESTIONS，可以仅返回空列表。在一些实施中，合作性文档编辑应用可以通过生成拒绝当前在该模型内的所有建议的命令集，来实施Projection.WITHOUT_SUGGESTIONS。

在一些实施中，以下的方法可以用于生成省略命令(可以是示出以上的步骤3.b.i的示例伪代码段)。

可以如下实施该方法：

1.AbstractCommand将返回空(null).

2.因为在未打开的情形下，可能不会计算细节，所以WrapperCommands将会对这些命令的调用报错。

3.建议命令将返回适当的省略命令。例如：

a.针对被插入范围，InsertSuggestedSpacers将返回DeleteSpacers。

b.针对同一范围，MarkSpacersForDeletion将返回UnmarkSpacersForDeletion。

这可以在ModelStateImpl中实施，并用于在广播修改之前变换修改中的命令，以及在返回LoadResult之前过滤它。这可以包括对API修改的以下修改：

在一些实施中，因为每一个命令必须取决于它是否是建议命令而被不同地对待，所以可以在处理之前打开命令。在一些实施中，由于每一个步骤中的模型不必然有效，因此合作性文档编辑者可能不使用合法变换器用于该处理。在一些实施中，合作者选择Changes使用Changes的修订版的模型，并且可保存的Changes使用之前的修订版的模型。

在一些实施中，本公开依赖于变换，以使得在命令被发送给查看者之前过滤命令。该方法的顾虑之一在于性能。特别地，如果文档具有建议和查看者，则变换可能减速且可能在每一次保存时执行。为了解决这一顾虑，可以对变换器执行性能测试。然而，因为一般的方法是n2，所以增益可能受限。为了避免最差情形的场景，相对于该命令执行变换的过滤命令的量可能受限，并且如果达到该极限，那么可以停止对查看者的广播。

另一顾虑在于，在ModelState锁定之后，可能立即执行广播。为解决这一顾虑，可以使用单独的锁函数，其中该单独的锁函数调用广播，但是不阻止对ModelState的其它操作。

在另一实施中，可以实施识别会话AccessLevel。在一些实施中，为了确定哪些会话需要广播信道过滤，合作性文档编辑器应用应当具有指示哪些会话是查看者会话的信息。由于用户的访问级别可能不必然与客户端的有效访问相匹配，因此确定用户的AccessLevel可能并不足够。例如，编辑者可以在查看模式下选择查看文档的选项，或者校对者可以在查看模式下而不是在校对者模式下来选择查看文档的选项。为了实施这一点，会话创建函数AppSessionManager可以被修改以还接收会话的AccessLevel。还可以存在识别哪些会话具有给定AccessLevel的机制。

在一些实施中，为了落实(populate)AccessLevel，函数SessionInitiationInterpretor可以取回当创建会话时当前用户的AccessLevel。如果存在在强制的较低访问级别(比如查看)发起会话的@SessionInitiator的末端(endpoint)，那么这些可以被手动覆盖。为了手动覆盖，参数可以被添加到具有最优AccessLevel的@SessionInitiator，以替代有效的@SessionInitiator来使用。替代地，得到强制的较低访问级别的末端可以被移除，因此如果客户端能够访问则强制客户端刷新。

在另一实施例中，根据以下内容可以对用法分类：

Projection.WITHOUT_SUGGESTIONS的用法：

1.做缩略图。这一般应当通过ModelThumbnailer处理。

2.编索引。这一般应当通过Indexer处理。

3.社交标记。这一般应当通过Snippeter处理。

4.爬虫。

5.文档副本。

6.预览和发布。

Projection.FULL的用法：

1.合法发现和AbuseIAM。

2.查找出口和调试末端。

3.其它内部用法：检查合法评论、验证、拼写检查、变换。

Projection.fromAccessLevel的用法：

1.仅编辑者可用的末端：链接编辑、恢复、Maestro RPC、修订历史。

2.离线同步：ModelAction。

3.输出。这一般可以通过Exporter处理。

一些用法可以基于当前会话的有效访问。可以实施一些机制以确保维持会话和访问级别的一致性或单独地处理它们：

1.SessionInitiator动作和它们的有效访问：

a.fromAccessLevel：编辑、评论

b.WITHOUT_SUGGESTIONS：查看、NativeWebView

2.需要会话的有效访问的用法

a.初始载入模型字体。

b.打印和打印预览。

c.模型符合(catchup)请求

d.命令广播。

以下是在实际中本文所描述的技术的一些示例：

示例1：在建议后应用通常命令。

示例2：在建议后应用被建议命令和通常命令。

在一些实施中，代替在被发送给查看者之前使用操作性变换来变换命令，在被剔除之前，命令可以被匿名化，并且然后依赖于客户端来正确地变换它们。该实施可能不是所期望的，因为它仅涉及更大和更为复杂的修改。特别地，匿名化可以需要命令以及该命令的模型预应用，因此它将必须在应用时间执行。通过其它路径被发送到客户端的命令(比如变量改变)将需要应用。此外，在不破坏命令的操作性变换(以及可能的应用)语义的情形下，将需要建立匿名化系统。这可能对客户端性能(包括移动端)具有负面影响。特别地，在客户端的变换可能对用户具有甚至更差的性能影响，在客户端侧恰当处理该问题的方法可能需要修改离线存储。

本文所公开的系统和方法的另一个实施例包括通知用户由合作者对文档的修改的通知机制。在线合作性文档编辑应用中，编辑者一般希望具有对他们的文档的控制以及使合作者处理文档。编辑者需要知道谁已经修改了他们的文档、文档何时被修改、以及被修改了什么。通过提供通知编辑者(以及订阅通知的用户)关于由合作者做出的对他们的文档的修改、连同修改的概要的方式，本公开的系统和方法解决了这一问题

图7提供了示出通知编辑者关于由合作者对合作性文档的修改的方面的示例性逻辑流图700。在701，现有系统可以追踪不同用户对文档做出的修改，但是不向用户提供修改或修改的概要的通知。在702，在一个实施例中，由合作者做出的修改可以基于从该修改起经过的时间量而被批处理。电子邮件或消息被发送给文档所有者和已选择订阅通知的用户。电子邮件或消息可以包含在给定时间段内来自多个合作者的修改。消息中的每个修改可以包括各种数据，比如作者、做出修改的时间、以及对修改的描述。修改可以由其他编辑者或者由不具备完全编辑权限的合作者(比如校对者)作出。由校对者做出的修改可以被记录为“建议”，并且在被应用于文档之前需要由编辑者同意。在一些实施中，编辑者可以通过选择适当的选项，直接从邮件或消息接受或拒绝这些修改。

在一些实施中，当对文档做出每次修改时，该修改被发送至通过文档和接收器来追踪修改事件的通知软件系统。文档所有者默认为订阅通知，其他合作者也可以订阅通知。在文档的同一区域或者在同一时间作出的修改可以被分组在一起。在703，通知软件系统然后等待可配置的时间量，该时间量可以基于接收器当前是否查看文档。

一旦在704已经过适当时间，则在705，针对接收器和文档的所有通知事件被分为一批并处理。针对向文档做出的每个修改，可以创建列出了作者、上次做出的修改的时间戳、以及修改的上下文描述的单独的项(在706)。

在一些实施例中，本公开包括用于确保编辑者不被过度通知的特征。已被恢复的修改和/或不再出现于该文档中的修改可以被忽略，并且针对这些修改的特征可以被抑制。例如，如果合作者对该文档做出了修改并且经过了该时间段，那么编辑者可以接收描述该修改的电子邮件。然而，如果合作者使用了取消功能，手动地取消该修改，或者如果该修改所驻留的文档章节被编辑者删除，那么可以抑制修改的通知。

基于正在查看文档的编辑者是否允许正在主动查看文档的编辑者对由用户做出的编辑采取行动并阻止发送冗余通知同时仍发送及时通知，使用不同的时间段。在一个示例中，如果编辑者正在主动查看文档，那么时间段可以更长，并且如果编辑者未主动查看文档，那么时间段可以更短。

本文所描述的系统和方法提供了对文档做出的修改的人类可读解释，并向编辑者提供了可以用于确定是现在、以后还是从不查看文档的信息。当编辑者仅被提供以必须手动检查的时间戳时，或者当编辑者必须依赖于合作者来通知编辑者存在修改以及修改所包括的内容时，这样的确定可能是不可能的。

本文所描述的实施例提出了相比现有系统的若干优势。例如，本文所描述的通知系统意味着当合作者已做出修改时，编辑者不需要由合作者人工通知。类似地，编辑者不需要自身采取行动来发现修改，因为在合作者修改之后，电子邮件或消息将很快被发送。此外，在消息中包括修改的描述向编辑者给出了关于该修改的上下文。仅提供时间戳更新不足以使编辑者确定修改的调查是否是受担保的。本公开向编辑者提供了使他更好地管理他在多个任务、包括该文档当前进行的合作之间的时间的信息。

在一些实施中，信息可以不仅包括文本描述，还包括文档的其余部分的上下文中的修改的渲染。例如，如果合作者利用新文本替换了一些文本，则消息中的描述不仅告知“利用‘a final part of something’替换‘end’”，而且该文档中周围的一些行、单词、或句子也可以被包括在该消息中。

在一些实施中，修改的概要可以被包括在消息通知中。以下的描述是用于通知编辑者和订阅者关于文档中修改的过程的示例。CommentNotificationListener可以监听事件，只要评论或回复被创建、更新、或删除，则该事件可以发生。事件可以被处理，并且可以创建通知有效载荷(如果环境担保通知)。通知器然后可以将通知有效载荷打包并将其发送至消息系统，消息系统接收该有效载荷并将其添加至(文档，接收器)的容器中。容器可以被维持以可配置的时间量(例如，比如如果文档被关闭，那么5分钟；如果文档由将被通知的用户打开，那么15分钟)。由于更多评论或回复被添加或更新，因此它们被添加至(文档，接收器)的同一容器。当已经过该时间段时，消息系统获得给定容器中的所有有效载荷并将其发送至被配置为处理该容器的消息处理器。消息处理器将容器传送至事件处理器，该事件处理器处理通知事件、过滤不应当被发送的事件、通过评论id将事件分组、以及将事件转换为html和文本消息体。

虽然已示出了本文所描述的各个实施例，但是对本领域的技术人员，显然这些实施例仅通过示例的方式被提供。大量的变动、修改和替换现在将由本领域的技术人员实行，而不背离本公开。应当理解，对本文所描述的本公开的实施例的各种替代，可以在实施本公开时采用。

本文所描述的系统和方法的另一个实施例包括由合作者通知对文档的修改的用户的通知机制。文档编辑器应用可以允许用户做出作为建议的编辑，该建议被追踪，并且在它们被并入该文档之前必须被接受或拒绝。为此，文档编辑器需要将任何任意编辑变换为建议版本的机制。期望具有能够一般地转换现有编辑而无需手动实施针对每一个编辑的转换逻辑的自动转换机制。这允许利用所有现有的控制器商业逻辑，包括已被记录的任何以后的逻辑。

如连同图6所讨论的，对文档模型的修改可以经由一系列增量式原子变化来描述。在单词处理器中，变化可以包括插入字符、删除字符以及应用样式。对文档的单个用户编辑可能得到应用于模型的多个变化。单词处理器将具有基于用户动作和应用的当前状态来确定将哪些变化应用于模型的商业逻辑。

图8提供了示出将编辑变换为建议的方面的示例性逻辑流图800。起始于801，在801，应用定义了其变化的建议性版本以识别应用模型中的被建议对象。例如，单词处理器可能具有插入字符变化和插入被建议字符变化。然后，应用需要定义从一般性形式向建议性形式转换的函数。在之前的示例中，这将是从插入字符向插入建议性字符转换的函数。如果建议性变化具有不同于原始变化的应用语义，那么必须还提供该建议性变换变化。

为了说明不同语义，这些变化将用于变换以后的变化。例如，单词处理器可能具有删除字符变化，其建议性版本是标记字符用于删除。然而，标记字符用于删除并不实际上删除它们-它仅创建了删除它们的建议。例如，用户执行拖放，这被表示为在索引100处删除字符并在索引200处插入字符。简单的转换将这些转换为在索引100处标记字符用于删除且在索引200处插入字符。然而，原始插入操作的索引假定该字符已被删除。因此，可以定义在100处插入字符作为建议性变换变化。相对于这一操作变换在200处插入字符使得该字符向前移动至正确位置用于插入。

一旦这些语义已被定义用于给定应用的模型，那么可以基于以下步骤生成建议：

1.将M定义为当前的应用模型(在802)

2.制作M的副本以生成M’(在802)

3.运行用户对M’的当前操作的商业逻辑。将作为该逻辑的结果的应用于M’的变化收集到队列A中(在803)

4.定义空队列T(在804).

5.对A中的每一个变化C:

a.经由应用专用函数，生成S和C的建议性版本

b.经由应用专用函数，生成F和针对C的建议性变换变化

c.相对于T变换S，以生成S’和T’

d.设置T＝T’

e.将F添加到T

f.将S’应用于M。

这将把变化的建议性版本应用于当前模型(在805)。在完成方法后，当前模型将使得用户动作的建议性版本应用于该方法。

当定义生成建议性变化的函数时，考虑被影响的对象的所有权可能是有用的。例如，如果用户对被建议单词退格，那么该单词将被删除；但是如果对非被建议单词退格，它将被标记用于删除。为了实现这一点，定义变化所有权的概念。所有权可以处于三种状态之一：被拥有、被部分拥有或不被拥有。在以上方法的步骤(3)中，基于每一个变化在模型中影响的对象，计算每一个变化的所有权。例如，如果文本是由当前用户提出的建议，那么删除该文本的变化将是被拥有的，否则，不被拥有；并且如果被删除文本的仅一部分是由当前用户提出的建议，那么被部分拥有。那么，在步骤(5.a)中，被预计算的所有权可以在转换过程期间中使用。对于删除字符的变化，其所有权可以用于澄清是转换为标记字符用于删除还是使其成为被删除的字符。

在步骤(3)中，还可以跨越类似类型的变化来聚集所有权。通过查看该聚集的所有权，当转换时，可以跨越分开的特定变化做出决定。这一点可能是有用的，例如，如果应用考虑不连续的选择操作，期望一致性地删除该文本或将其标记用于删除。

以这种方式解决该问题具有以下优势：

1.它是与应用专用商业逻辑无关的一般性解决方案。它仅需要定义应用中的变化的转换函数。这使实施的开销最小。

2.因为它与应用专用商业逻辑无关地运行，所以当应用被利用新的商业逻辑来扩展或修改时，它需要较小的维护开销。

3.在模型中将建议扩展至新对象是直接的。只必须仅定义用于向这些对象呈现修改的变化的转换函数。

为了生成建议命令，接口SuggestCommandProvider可以经由CommandRegistry被引入具有注册表。可以采取另一接口SuggestTransformCommandProvider，该接口将创建提供命令和建议命令之间的映射的命令。示出SuggestCommandProvider和SuggestTransformCommandProvider的示例伪代码段可以采取类似于以下的形式：

/**创建命令的建议版本。*/

interface docs.commands.SuggestCommandProvider{

/**利用给定的建议id，针对给定命令，获取对应的建议命令。*/

SuggestCommand provideSuggestCommand(command,id,model)

}

interface docs.commands.SuggestTransformCommandProvider{

/**给定建议性命令，返回将用于在同一编辑内变换以后建议的命令。该

*命令将解释命令和如被getSuggestCommand返回的建议命令之间的不同

*语义。*/

Command provideSuggestTransformCommand(command)

}

class docs.commands.CommandRegistry implementsdocs.commands.SuggestCommandProvider,

docs.commands.SuggestTransformCommandProvider{

/**@override*/

Command provideSuggestCommand(command,id,model)

/**@override*/

Command provideSuggestTransformCommand(command)

}

/**注册SuggestCommandProvider*/

void registerSuggestCommandProvider(type,provider)

/**注册SuggestTransformCommandProvider*/

void registerSuggestTransformCommandProvider(type,provider)

}

该文档模型可以制作上下文的副本，以在不修改实际的ModelState的情况下应用原始编辑。为此，可以创建改变复制上下文的指定接口的建议。这不是一般的上下文复制器，因为它将处理特定于建议性修改中的用法的事件，比如创建无操作的反向器。

/**复制上下文。*/

interface docs.edits.ContextCopier{

/**创建将被SuggestEdit使用的给定上下文的副本。*/

Context copy(context)

}

/**复制用于在SuggestEdit中使用的文档/文本的上下文。*/

class docs.text.edits.SuggestContextCopier implementsdocs.edits.ContextCopier

(commandApplier,selectionTransformer){

/**@override*/

Context copy(context){

var model＝context.getModelState().getModel().copy()；

var selectionModel＝new docs.text.model.SelectionModelImpl(

context.getErrorReporter(),model)；

selectionModel.setSelection(

context.getModelState().getSelectionModel().getSelection())；

var modelState＝new docs.text.edits.ModelState(

model,

selectionModel,

commandApplier,

new NoOpCommandInverter(),

selectionTransformer)；

return new docs.text.edits.Context(

modelState,

context.getLinkDefaults(),

context.getErrorReporter())；

}

interface docs.text.model.Model{

/**复制该模型*/

Model copy()

}

class docs.text.model.ModelImpl implements docs.text.model.Model{

/**@override*/

Model copy(){

var newModel＝new ModelImpl(

this.errorReporter_,

this.styleResolvers_,

this.concreteStyleUpdaters_,

this.entityConcreteStyleUpdaters_,

this.entityResolvers_,

this.enabledStyleTypes_,

this.contentClassifier_)；

this.copyTo(newModel)；

return newModel；

}

}

class docs.text.model.ModelWrapper implements docs.text.model.Model{

/**@override*/

Model copy(){

return this.modelProviderFn_.copy()；

}

}

为了执行以上所概述的SelectionModel复制，SelectionTreeGenerator和SelectionDocumentSliceGenerator将从SelectionModel被移除，并且移动到helper类：

class docs.text.dom.DocumentSliceGenerator(

selectionTreeGenerator,selectionDocumentSliceGenerator){

/**创建代表给定模型中的给定选择的文档部分。*/

DocumentSlice createDocumentSlice(model,selection){

var root＝this.selectionTreeGenerator_.generateTree(

model.getSpacers(),selection.getSelectedRanges())；

return this.selectionDocumentSliceGenerator_.generate(

model,selection,root)；

}

}

为了引入SuggestEdit，可以将IdUtil从docs.text.util移动到docs.util。以下是两个新类的概述：

/**提供建议性编辑*/

class docs.edits.SuggestEditProvider implementsdocs.edits.EditProvider(

editProvider,

commandTransformer,

selectionTransformer,

suggestCommandProvider,

suggestTransformCommandProvider,

contextCopier){

Edit provideEdit(context){

return new SuggestEdit(

context,

this.editProvider_.provide(

this.contextCopier_.copy(context)),

this.commandTransformer_,

this.selectionTransformer_,

this.suggestCommandProvider_,

this.suggestTransformCommandProvider_)；

}

boolean canApply(context){

return this.editProvider_.canApply(context)

}

}

/**将给定编辑应用为建议。*/

class docs.edits.SuggestEdit extends docs.edits.AbstractEdit(

context,edit,commandTransformer,selectionTransformer,suggestCommandProvider,

suggestTransformCommandProvider){

void applyInternal(args){

var result＝this.edit_.apply(args)；

var id＝docs.util.IdUtil.generateId(‘suggest’)；

var transformCommands＝[]；

for each command in result.getCommands(){

//因为在该模型中采取provideSuggestCommand，所以必须解封.

if(command.isWrapper()){

for each innerCommand in command.unwrap(){

this.applySuggestCommand_(innerCommand,transformCommands)；

}

}else{

this.applySuggestCommand_(command,transformCommands)；

}

}

this.applySelection(this.selectionTransformer_.transformSelection(

result.getSelectionAfter(),transformCommands))；

}

private void applySuggestCommand_(command,transformCommands){

var suggestCommand＝this.suggestCommandProvider_.provideSuggestCommand(

command,id,model)；

var pair＝this.transformer_.transformBoth([suggestCommand],transformCommands)；

transformCommands＝pair.getCommands()；

assert(pair.getCommandsToWin().length＝＝1)；

var transformedSuggestCommand＝pair.getCommandsToWin()[0]；

var newTransformCommand＝

this.suggestTransformCommandProvider_.provideSuggestTransformComma nd(

suggestCommand)；

//因为该newTransformCommand通常将是NullCommand，所以为了性能而解封.

var newTransformCommands＝newTransformCommand.isWrapper()？

newTransformCommand.unwrap():[newTransformCommand]；

goog.array.extend(transformCommands,newTransformCommands)；

this.applyCommand(transformedSuggestCommand)；

}

}

注意到，在SuggestEdit.applyInternal中的applySelection调用正在不恰当地传播“滚动进入视野”以及选择改变理由。这将在以后的工作中解决，现在这些问题将被忽略。

每当应用处于建议模式时，SuggestEditProvider需要被用于封装通常EditProvider。通过引入SuggestEditApplier封装器，这可以被实现。

/**提供建议性编辑。*/

class docs.edits.SuggestEditApplier implements docs.edits.EditApplier(delegate,

commandTransformer,selectionTransformer,suggestCommandProvider,

suggestTransformCommandProvider,contextCopier){

/**@override*/

void apply(editProvider,args){

if(this.suggestionsMode_){

editProvider＝new SuggestEditProvider(

editProvider,

commandTransformer,

selectionTransformer,

suggestCommandProvider,

suggestTransformCommandProvider,

contextCopier)；

}

this.delegate_.apply(editProvider)；

}

void setSuggestionsMode(enabled){

this.suggestionsMode_＝enabled；

}

}

这允许拦截被应用的所有编辑提供器，并且适当地封装它们。取消或通常重做可以不需要被拦截，因为它们将正确地应用来自于SuggestEdit的结果的命令。此外，关键(magic)的重做可以不需要被拦截，因为被保存的提供器将已是正确的提供器。在建议修改flag之后，在合作性文档中将创建SuggestEditApplier。如果用户处于评论模式，那么setSuggestionsMode将被使能。

图9为表述示例性计算机系统900的框图，利用该系统，用于图1-8的用途以及在文档中管理被建议编辑的系统可以被实施。在某些方面，计算机系统900可以使用硬件或软件和硬件的组合来实施，或者在专用服务器中、或者被集成为另一实体、或者跨越多个实体分布。

计算机系统900包括用于传递信息的总线908或其它通信机制，并且处理器902与总线908耦合以处理信息。通过示例的方式，计算机系统900可以利用一个或多个处理器902来实施。

除了硬件以外，计算机系统900可以包括代码，代码创建用于所讨论的计算机程序的执行环境，例如，构成处理器固件、协议栈、数据库管理系统、操作系统、或他们的一个或多个的组合的代码存储于被包括的存储器904中，比如随机访问存储器(RAM)、闪速存储器、只读存储器(ROM)、可编程只读存储器(PROM)、可擦除PROM(EPROM)、寄存器、硬盘、可移除盘、CD-ROM、DVD、或任何其它适当地存储设备，耦接至总线908用于存储信息和将被处理器902执行的指令。处理器902和存储器904可以被逻辑电路补充，或并入逻辑电路中。

本文所描述的系统和方法可以通过在服务器、客户端、防火墙、网关、集线器、路由器、或其它这类计算机和/或联网硬件上执行计算机程序的机器，部分地或整体上被部署。软件程序可以与服务器相关联，该服务器可以包括文件服务器、打印服务器、域服务器、互联网服务器、内部网服务器以及其它变体，比如副服务器、主机服务器、分布式服务器等。服务器可以包括一个或多个存储器、处理器、计算机可读介质、存储介质、端口(物理端口和虚拟端口)、通信设备、以及能够通过有线或无线媒介来访问其它服务器、客户端、机器和设备的接口等。如本文和其它地方所描述的方法、程序或代码可以有服务器执行。另外，执行如该应用中所描述的方法所需的其它设备可以被认为是与该服务器相关的设施的一部分。

服务器可以提供到其它设备的接口，包括但不限于客户端、其它服务器、打印机、数据库服务器、打印服务器、文件服务器、通信服务器、分布式服务器等。另外，该耦接和/或链接可以促进跨越网络的远程执行程序。在不背离所公开的主题的范围的情形下，这些设备的一部分或所有的联网可以促进程序或方法在一个或多个位置处并行执行。另外，通过接口附接至服务器的任何设备可以包括至少一个能够存储方法、程序、代码和/或指令的存储介质。中央仓储系统可以提供在不同设备上执行的程序指令。在该实施中远程仓储系统可以用作程序代码、指令、以及程序的存储介质。

本文所描述的方法和系统可以通过网络设施来部分地或整体上部署。网络设施可以包括以下元件，比如计算设备、服务器、路由器、集线器、防火墙、客户端、个人电脑、通信设备、路由设备以及本领域中已知的其它主动和被动设备、模块和/或组件。与网络设施相关的计算设备和/或非计算设备可以包括(除其它组件以外)存储介质，比如闪速存储器、缓存、栈、RAM、ROM等。本文和其它地方所描述的过程、方法、程序代码、指令可以由网络设施元件的一个或多个执行。

计算机软件、程序代码、和/或指令可以存储于机器可读介质上和/或在机器可读介质上访问，该机器可读介质包括：计算机组件、设备、以及保持用于一些间隔时间的计算的数字数据的记录介质；半导体存储设备被认为是随机访问存储器(RAM)；大容量存储设备通常用于更为持续的存储，比如光盘、磁存储设备的形式，比如硬盘、磁带、磁鼓、磁卡以及其它类型；处理器寄存器、缓存存储器、易失性存储器、非易失性存储器；光存储设备，比如CD、DVD；可移除介质，比如闪速存储器(例如，USB存储棒或USB加密设备)、软盘、磁带、纸带、穿孔卡、独立式RAM盘、极碟驱动器、可移除大容量存储设备、离线等；其它计算机存储器比如动态存储器、静态存储器、读/写存储设备、可变存储设备、只读存储设备、序列性访问存储设备、位置可寻址存储设备、文件可寻址存储设备、内容可寻址存储设备、附接至网络的存储设备、存储区域网络、条形码、磁性墨水等。

本文，包括在各处附图的流程图和框图，所描述的元件暗示了这些元件之间的逻辑界限。然而，根据软件或硬件在工程上的实施，其中所描述的元件和功能可以通过计算机可执行介质在机器上实施，该机器具有能够执行存储于其上的程序指令的处理器，该程序指令作为整体式软件结构、独立的软件模块、或采用外部例程、代码、服务等的模块，或者它们的任意组合，所有这些实施可以在本公开的范围之内。

因此，虽然前述的附图和描述阐述了所公开系统的功能性方面，但是除非明确提及或以其它方式从上下文可见，不存在用于实施这些功能性方面的软件的特定布置应当从这些描述被推断。类似地，将能理解以上所识别和描述的各种技术可以被改变，并且技术的顺序可以适应于本文所公开的技术的特定应用。所有这些变体和修改意图落在本公开的本公开的范围之内。由此，各种技术的顺序的描绘和/或描述不应当被理解为需要执行这些技术的特定顺序，除非被特定应用所需，或者明确提及或以其它方式从上下文可见。

以上所描述的方法和/或过程，以及其中的技术，可以在硬件、或者适合于特定应用的硬件和软件的任意组合中实现。硬件可以包括通用计算机和/或专用计算设备或具体计算设备或具体计算设备的特定方面或组件。该过程可以在一个或多个具有内部和/或外部存储器的微处理器、微控制器、嵌入式微控制器、可编程数字信号处理器或其它可编程设备中实现。处理器还可以，或替代地，被体现在具体于应用的集成电路、可编程门阵列、可编程阵列逻辑、或可以被配置为处理电信号的任何其它设备或设备的组合。还将理解，一个或多个过程可以被实现为能够在机器可读媒介上执行的计算机可读代码。

指令可以被存储在存储器904内并在一个或多个计算机程序产品中实施，即，计算机程序指令的一个或多个模块被编码在计算机可读介质上，用于被服务执行，或者控制服务的操作，并且根据本领域的技术人员所公知的任何方法，包括但不限于计算机语言，比如面向数据的语言(例如，SQL、dBase)、系统语言(例如，C、Objective-C、C++、汇编)、架构语言(例如，java、.NET)以及应用语言(例如，PHP、Ruby、Perl、Python)。

如本文所讨论的计算机程序不必然对应于文件系统中的文件。程序可以被存储在文件的一部分，该文件保存其它程序或数据(例如，存储于标记语言文档中的一个或多个脚本)，或者被存储在专用于所讨论的程序的单个文件中，或者被存储在多个协调性文件(例如，存储一个或多个模块、子程序、或部分代码的文件)中。计算机程序可以被采用以在一个计算机上或在多个计算机上执行，该多个计算机位于一个地点，或跨越多个地点被分布式布置并通过通信网络互连。本说明书中所描述的过程和逻辑流可以由执行一个或多个计算机程序的一个或多个可编程处理器执行，以通过对输入数据操作并生成输出来施行功能。

计算机系统900还包括耦接至总线908用于存储信息和指令的数据存储设备906，比如磁盘或光盘。计算机系统900可以经由输入/输出模块910耦接至各种设备。输入/输出模块910可以为任何输入/输出模块。示例输入/输出模块910包括数据端口，比如USB端口。输入/输出端口910被配置为连接图形模块912。示例图形模块912包括联网接口卡，比如以太网卡和调制解调器。在某些方面，输入/输出模块910被配置为连接多个设备，比如输入设备914和/或输出设备916。示例输入设备914包括键盘和点击设备，例如，鼠标或轨迹球，通过该输入设备，用户可以向计算机系统900提供输入。输入设备914的其它种类还可以用于提供与用户的交互，比如触觉输入设备、可视化输入设备、声音输入设备、或大脑计算机输入设备。例如，被提供给用户的反馈可以是任何形式的感官反馈，例如，视觉反馈、听觉反馈、或触觉反馈；并且来自用户的输入可以以任何形式接收，包括声音、语音、触觉、或脑波输入。示例输出设备916包括语音向用户显示信息的显示设备，比如CRT(阴极射线管)或LCD(液晶显示)监视器。

根据本公开的一方面，响应于处理器902执行包含于存储器904的一个或多个指令的一个或多个序列，如在图2A-7中示出的用于在文档模型中管理被建议编辑的系统，可以使用计算机系统900来实施。该指令可以从另一个机器可读媒介，比如数据存储设备906，读入存储器904中。包含在主存储器904的指令序列的执行使得处理器902执行文本所描述的过程。多处理布置中的一个或多个处理器还可以用于执行包含在存储器904中的指令序列。在替代的方面，硬连线电路可以用于替换软件指令或与软件指令相组合以实施本公开的各个方面。因此，本公开的方面不限于硬件电路和软件的任何具体组合。

本说明书中所描述的主题的各个方面可以在计算系统中实施，该计算系统包括后端组件，例如数据服务器、或者包括中间件组件的数据服务器、例如应用服务器、或者包括前端组件的应用服务器、例如具有图形用户接口或网络浏览器的客户端计算机(通过该图形用户接口或网络浏览器，用户可以与本说明书中所描述主题的实施交互)、或者一个或多个这样的后端、中间件、或前端组件的任意组合。系统的组件可以通过数字化数字通信的任何形式或媒介(例如通信网络)而被互相连接。通信网络可以包括例如，个域网(PAN)、局域网(LAN)、校园网(CAN)、城域网(MAN)、广域网(WAN)、宽带网(BBN)、互联网等的一个或多个。此外，通信网络可以包括但不限于，例如且不作为限制，企业服务器或服务器群、一个或多个台式计算机、一个或多个笔记本电脑等。计算机系统900还可以被嵌入到另一涉笔中，例如且不作为限制，移动电话、个人数字助理(PDA)、移动音频播放器、全球定位系统(GPS)接收器、视频游戏控制台、和/或电视机机顶盒。

如以上所讨论的，计算系统900可以包括客户端和服务器。客户端和服务器一般远离彼此，并且通常通过通信网络交互。借助于在各自的计算机上运行的计算机程序以及具有彼此的客户端-服务器联系，产生客户端和服务器的关系。计算机系统900可以为，例如且非限制，企业服务器或服务器群、一个或多个台式计算机、一个或多个笔记本电脑等。计算机系统900还可以被嵌入在另一设备中，例如且非限制，移动电话、个人数字助理(PDA)、移动音频播放器、全球定位系统(GPS)接收器、视频游戏控制台、和/或电视机机顶盒。

如本文所使用的术语“机器可读存储媒介”或“计算机可读媒介”指代参与向处理器902提供指令用于执行的任何媒介或介质。该媒介可以采取许多形式，包括但不限于，非易失性介质、易失性介质、以及传输介质。非易失性介质包括例如光盘或磁盘，比如数据存储设备906。易失性介质包括动态存储器，比如存储器904。传输介质包括通知电路、铜线、以及光纤，包括构成总线908的电线。机器可读介质的通常形式包括，例如软盘、柔性盘、硬盘、磁带、任何其它磁性媒介、CD-ROM、DVD、任何其它光媒介、穿孔卡、纸带、具有多孔图案的任何其它物理媒介、RAM、PROM、EPROM、闪速EPROM、任何其它存储器棒或墨盒、或计算机可以从其读取的任何其它介质。机器可读存储介质可以是机器可读存储设备、机器可读存储基质、存储器设备、影响机器可读的传播信号的物质的组分、或者它们的一个或多个的组合。

虽然本说明书包含许多细节，但是这些细节不应当被解释为对可能被要求的内容的范围上的限制，而是应当作为主题的特定实施的描述。在本说明书中于单独的实施的环境中所描述的某些特征，还可以在单个实施中以组合的形式实施。反之，在单个实施的环境中所描述的各个特征，还可以在多个实施中被单独地或以任何适当的子组合的形式来实施。此外，虽然特征可以在以上被描述为在某些组合中动作且甚至最初时要求如此，但是来自被要求的组合的一个或多个特征可以在某些情形下从该组合删除，并且所要求的组合可以指向子组合或子组合的变体。

虽然在附图中，操作以特定顺序被描述，但是这不应当被理解成为了获得所需结果，需要这些操作以所示的该特定顺序或顺序执行。在某些环节下，多任务和并行处理可以是有利的。此外，在以上所描述的方面中的各个系统组件的分离不应当被理解为在所有方面需要这种分离，并且应当理解，所描述的程序组件和系统可以一般地一并集成在单个程序产品中或者被打包为多个程序产品。

虽然本说明书的主题已根据特定方面被描述，但是其他方面可以被实施，并且在以下的权利要求的范围之内。例如，权利要求中记载的动作可以按照不同的顺序执行，并仍然实现所期望的结果。作为示例，附图中所描述的过程不必然需要所示的特定顺序、或顺序以实现所期望的结果。在某些实施中，多任务和并行处理可以是有利的。其它变体处于以下的权利要求的范围之内。

Claims (21)

1.一种在合作性文档中管理被建议编辑的方法，所述方法包括：

实例化与所述合作性文档相关联的文档模型；

从第一用户接收对所述合作性文档的第一编辑建议；

基于所述第一编辑建议的类型和所述文档模型的类型，将第一建议命令与所述第一编辑建议相关联；

在所述文档模型上应用所述第一建议命令，以在所述合作性文档内呈现所述第一编辑建议；

接收针对所述第一编辑建议的接受指示；并且

响应于所述所接收的接受指示，利用所述第一建议命令更新所述文档模型。

2.如权利要求1所述的方法，还包括：

验证所述第一用户的权限状态，其中所述权限状态包括以下的任何：

校对者，被授权在所述合作性文档上查看、做出被建议编辑以及提供评论；

编辑者，被授权接受或拒绝被建议编辑以及删除由所述校对者做出的评论；或者

查看者，被授权查看所述合作性文档的不包括被建议编辑或评论的指示的干净的已发布版本。

3.如权利要求1所述的方法，其中，所述第一编辑建议包括以下的任何：

将对象插入所述文档模型；

从所述文档模型删除对象；

修改附接至所述文档模型中的对象的属性；

在所述文档模型内移动对象；或者

利用另一对象替换所述文档模型内的对象。

4.如权利要求1所述的方法，其中，所述第一建议命令包括表述被建议编辑的标记或注释。

5.如权利要求1所述的方法，其中，从不同于所述第一用户的第二用户接收所述接受指示。

6.如权利要求1所述的方法，还包括：

接收对所述合作性文档的第二编辑建议；

在所述文档模型上应用第二建议命令，以在所述合作性文档内呈现所述第二编辑建议；

接收针对所述第二编辑建议的拒绝指示；并且

从所述合作性文档移除所述第二编辑建议。

7.如权利要求1所述的方法，还包括：

接收针对所述文档模型的过滤命令；

在所述文档模型上应用所述过滤命令以创建新的文档模型；

在保持所述文档模型的同时，经由用户接口呈现所述新的文档模型的视图。

8.如权利要求7所述的方法，其中，所述新的文档模型是所述文档模型的副本。

9.如权利要求1所述的方法，还包括：

接收对所述合作性文档的第二编辑建议；

基于与所述第一编辑建议相关联的第一标识符和与所述第二编辑建议相关联的第二标识符，确定所述第二编辑建议在所述第一编辑建议之内被创建；并且

合成所述第一编辑建议和所述第二编辑建议。

10.如权利要求1所述的方法，还包括：

接收对所述合作性文档的第二编辑建议；

确定所述第二编辑建议与所述第一编辑建议相冲突；并且

经由用户接口，呈现所述第一编辑建议和所述第二编辑建议。

11.如权利要求1所述的方法，其中，所述第一编辑建议以包括关于以下任何内容的信息的格式被呈现：所述第一用户的身份、建议时间戳、解释所述第一编辑建议为何的元数据、或者所述第一编辑建议的接受或拒绝状态。

12.如权利要求1所述的方法，还包括：

确定与所述第一编辑建议相关联的变化；

定义所述文档模型内所述变化将与其合并的潜在的编辑建议的优先级列表；

至少部分地基于至少一个潜在的编辑建议的优先级级别和所述变化，根据所述优先级列表检查所述变化是否与所述至少一个潜在的编辑建议合并；

当所述变化将被合并时，将所述第一编辑建议与所述至少一个潜在的编辑建议合并；并且

当所述变化不被合并时，将所述第一编辑建议呈现为新的编辑建议。

13.如权利要求12所述的方法，还包括：

确定与所述第一编辑建议相关联的第一标识符；

当所述至少一个潜在的编辑建议与和所述第一标识符相同的标识符相关联时，将所述变化与所述至少一个潜在的编辑建议合并。

14.如权利要求1所述的方法，还包括：

确定与所述第一编辑建议相关联的一个或多个变化；

定义与所述一个或多个变化相关联的投射；

利用所述投射更新所述文档模型；

从所述一个或多个变化，确定相对于所述投射的第一变化n；

呈现所述更新后的文档模型而不应用其它变化。

15.如权利要求14所述的方法，其中，基于所述一个或多个变化应用于其上的所述文档模型以及从所述一个或多个变化省略哪些变化，所述投射被定义。

16.如权利要求1所述的方法，还包括：

识别来自于所述第一用户的对所述文档模型的第一修改；

在第一时间戳批处理所述第一修改而不实时发送合作者的通知；

在第二时间戳，收集并且向所述合作者发送涉及所述第一修改的通知，其中所述第二时间戳晚于所述第一时间戳。

17.如权利要求16所述的方法，还包括：

识别所述第一时间戳和所述第二时间戳之间的第二修改；

确定所述第二修改抵消所述第一修改；并且

从所述通知排除所述第一修改。

18.如权利要求1所述的方法，还包括：

接收所述文档模型内的第一编辑；

定义与所述第一编辑相关联的变化的建议版本；

基于所述变化的建议版本，确定第二编辑建议；

将所述第一编辑转换为所述第二编辑建议；并且

利用所述第二编辑建议，更新所述文档模型。

19.如权利要求18所述的方法，还包括：

基于所述文档模型中的对象，确定具有所述变化的所有权，其中所述对象被所述变化影响。

20.一种用于在合作性文档中管理被建议编辑的系统，所述系统包括：

用于实例化与所述合作性文档相关联的文档模型的装置；

用于从第一用户接收对所述合作性文档的第一编辑建议的装置；

用于基于所述第一编辑建议的类型和所述文档模型的类型，将第一建议命令与所述第一编辑建议相关联的装置；

用于在所述文档模型上应用所述第一建议命令，以在所述合作性文档内呈现所述第一编辑建议的装置；

用于接收针对所述第一编辑建议的接受指示的装置；以及

用于响应于所述所接收的接受指示，利用所述第一建议命令更新所述文档模型的装置。

21.一种存储用于在合作性文档中管理被建议编辑的处理器可执行指令的处理器可读非暂时性介质，所述处理器可执行指令包括：

用于实例化与所述合作性文档相关联的文档模型的指令；

用于从第一用户接收对所述合作性文档的第一编辑建议的指令；

用于基于所述第一编辑建议的类型和所述文档模型的类型，将第一建议命令与所述第一编辑建议相关联的指令；

用于在所述文档模型上应用所述第一建议命令，以在所述合作性文档内呈现所述第一编辑建议的指令；

用于接收针对所述第一编辑建议的接受指示的指令；以及

用于响应于所述所接收的接受指示，利用所述第一建议命令更新所述文档模型的指令。