CN105051730B - 使用多个编辑器或特征的各版本的协作 - Google Patents

Abstract

提供了一系统，其中支持跨各种平台和特征版本的对文档的访问和协作。描述了转换和合并服务，其使得客户端设备能够显示文档而不管原始文件格式，并将所显示的文档的修改重新整合到原始文档中。在改变被比较并被合并到原始文档中之前，所显示的文档(作为整体或在部分上)可被导入并被转换成原始文档的文件格式。也提供了执行某些任务(诸如突出显示、评论或格式化)的应用编程接口的集合。

Description

使用多个编辑器或特征的各版本的协作

背景

随着协作软件改进，协作和文件共享正变得更容易。然而，不是每个设备都能支持共同创作和协作。一些设备没有准备好协作或要求访问和修改数字内容的所有系统运行相同的程序。一人访问、共享和共同创作数字内容的能力可部分取决于该人是否具有识别数字内容的格式的适当软件程序以及以下设备：该设备能执行该程序使得数字内容能被查看、修改并使得这些修改传播并当被另一人访问时(或另一平台上的同一人)反映为数字内容的一部分。

随着使用不同平台的设备的增长，对于使用运行仅能够访问和显示一格式或仅能够使用特征的较早版本编辑内容的程序的设备来共享、访问和编辑不同格式的内容可以是个挑战。此外，随着新特征被添加到某些应用的新版本，这些新版本必须支持向后兼容性和/或内置可扩展性以支持将来的版本。

发明内容

描述了促进使用多个编辑器或特征的各版本的协作的转换和合并服务。

根据一实施例，通过执行转换和合并服务的系统提供给客户端的文档是体验的集合和其内部的内容。文档可在系统可检索到的位置处被存储为具有第一文件格式的主文档，并且当被客户端请求时，该文档可被转换成适当的文件格式并被提供到客户端。所提供的文档还可将在客户端处支持的特征的版本考虑在内。

所提供的文档可被显示在客户端设备处。服务扩展文档的可达范围(到跨各种平台的设备)并创建针对该文档的适合于客户端设备的体验。文档不需要在每个客户端上看上去完全相同。相反，文档可针对用户的体验并适合设备来被定制。一旦在客户端设备处被显示，用户可本地地修改该文档。修改可包括对于内容以及对于与该文档相关联的数据的修改。例如，可作出注释、评论、文本编辑、图像编辑以及其他修改。用户可接着将修改保存回服务器上。服务器可合并修改，即使在用户修改的文档具有不同的文件格式或包含特征的不同版本的情况下。

根据一个方面，提供了转换服务，其能将第一文件格式的文档变换成不同于第一文件格式的第二文件格式的文档。根据另一方面，提供了转换服务，其能将文档的内容从一个版本变换成另一版本。根据又一方面，转换服务可基于客户端约束和能力来提供附加的调节。根据又一方面，提供了合并服务，其合并对不同文件格式或版本的文档作出的修改。

转换服务使得文档的内容能针对文档在其上被查看的每个客户端来定制并且合并服务使得对文档的修改能与主文档重新整合。主文档可以是内容和对文档作出的修改的聚集。在一些情况下，主文档可看上去为最高保真度文档。由此，当从较低保真度编辑器中作出的修改或使用特征的较早版本的修改被重新整合到主文档中时，合并服务可执行保真度再融合(rehydration)。

提供本概述是为了以精简的形式介绍将在以下详细描述中进一步描述的一些概念。本发明内容并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。

附图说明

图1显示了其中可实现某些实施例的操作环境的图。

图2显示了根据本发明的一实施例的端点的操作环境。

图3显示了根据本发明的一实施例的计算环境。

图4显示了根据本发明的一实施例的用于转换和合并服务的示例过程流。

图5A-5D示出了转换和合并服务的示例场景。

图6显示了根据本发明的一实施例的由编辑器实现的过程的图。

图7显示了根据本发明的一实施例的用于使用多个编辑器在文档上协作的方法的过程流程图。

图8示出了解说在一些实施例中使用的计算设备的各组件的框图。

具体实施方式

公开了启用各种平台上的可访问性和协作的内容访问服务。通过内容访问服务，内容可被提供给消费者，而无需消费者必须意识到内容可能实际上具有与一般经由他们的设备可用或可查看的文件格式不同的文件格式。根据某些实施例，消费者可与文件格式改变并且在一些情况下与对跨平台查看、访问和修改内容的限制相隔离。本文中描述的技术、界面和方法可被用于促进将用户体验从文件和格式移至场景驱动的体验。

电子文档一般被理解为等同于纸件文档的数字化，其中文档编辑器促进对内容的创建、注释、修改以及(近来的)共享和协作。

修改可包括对于内容以及对于与该文档相关联的数据的修改。例如，可作出评论、文本编辑、图像编辑以及其他修改。文件的修改可包括添加、减少的动作，提供附加的内容、丰富内容的动作，添加评论的动作以及在图像编辑器内修改图像的动作。

本发明的某些实施例将新特征添加到文档——文档即服务，其中文档提供体验的集合以及它内部的内容。该体验的集合对应于服务的集合，该服务包括转换和合并服务的内容访问服务。转换服务使得文档的内容能针对文档在其上被查看的每个客户端来定制并且合并服务使得对文档的修改能与主文档重新整合。主文档可以是内容、元数据以及对文档作出的修改(包括对内容的修改以及对元数据的修改)的聚集。在一些情况下，主文档可看上去为最高保真度文档。

由此，当从较低保真度编辑器中作出的修改或使用特征的较早版本的修改被重新整合到主文档中时，服务可执行保真度再融合。

保真度再融合指取得被特征的较早版本修改的内容——或具有带有较少功能的编辑器的文件格式——并将内容返回到全功能、最新特征版本。作为一个示例，给定图形特征的两个版本——具有丰富图表(诸如3D图表)的第一版本和仅能够将图表解释为静态图像的第二版本，在内容在支持第二版本的编辑器中被编辑之后，静态图像可被再融合回3D图表以供在支持第一版本的编辑器中查看/编辑。第一版本可以是特征的将来或更高版本，而第二版本可以是特征的先前或较早版本。在其他情况下，两个版本可在同时被发布，但具有在可用功能方面的有意区别。

虽然主文档被称为文档，但是主文档可以用合适于跟踪内容和最新编辑特征的任意格式来存储。

通过这些服务，消费者设备可跨各个平台来访问和修改内容，而无需添加复杂性到客户端侧软件或消费设备。

文件格式(针对文档或其他内容以及相关信息)指藉此与文件的内容有关的信息(并且在一些情况下，相关联的信息)被编码并被存储在计算机可读介质上的方式。文件类型可与文件格式互换地使用，但一般指文件格式的分类。例如，文件类型可以是文档文件类型，其包括超文本标记语言(HTML)的文件格式、ADOBE便携文档格式(PDF)、MICROSOFT WORD文档(DOC)、办公开放可扩展标记语言(OOXML)格式(DOCX)等。MICROSOFT WORD是微软公司的注册商标；ADOBE PDF是奥多比系统公司的注册商标。

如本文中使用的，“消费格式”指由特定设备或软件程序支持的文件格式(例如，“支持的文件格式”)。除了是支持的文件格式之外，消费格式还可包括与文件大小、功能等有关的、关于设备(或程序)可如何能够支持各种用户体验的特征。

返回到文件即服务范例，包括转换和合并服务的内容访问服务可作为云服务体验的一部分来提供。通过这种方式，内容可以按一种格式来被创建并接着以可向内容的消费者提供无缝体验的方式来可跨任意平台访问和编辑。

图1显示了其中可实现某些实施例的操作环境的图。

参考图1，操作环境可包括一个或多个云或web服务。本文中描述的内容访问服务100可以是云服务或web服务。

云服务通常指提供可缩放处理和存储能力的托管服务。云计算通常可包括虚拟化的资源。由云计算呈现的资源本身被提供为服务，其中云计算客户从拥有物理基础设施的第三方提供者租用资源的使用。

web服务可由云服务(例如，作为大规模分布式计算环境的一部分)提供和/或主控。web服务是支持通过网络的互操作机器到机器交互并使得软件能够连接到其他软件应用的软件系统。

web服务提供技术标准和协议的集合。例如，web服务提供可由发送和接收消息的软件或硬件代理实现的功能(例如，请求和提供特定服务的计算平台)。应用可经由普遍存在的web协议和数据格式(诸如超文本传输协议(HTTP)、XML、JavaScript对象记法(JSON)以及SOAP(初始是简单对象访问协议的首字母缩略词))来访问web服务。

代表性状态传输(REST)协议在访问命名资源时是有用的并可被用在本发明的某些实施例中。在本发明的其他实施例中可利用SOAP。在一些情况下，可使用来自微软公司的HTTP上的经由SOAP的文件同步服务(FSSHTTP)。

可使用通过网络通信的一个或多个物理和/或虚拟服务器来实现内容访问服务100。该网络可包括但不限于蜂窝网络(例如无线电话)、点对点拨号连接、卫星网络、因特网、局域网(LAN)、广域网(WAN)、WiFi网络、自组织网络或其组合。这样的网络可被广泛地应用来连接各种类型的网络元素，诸如集线器、桥接器、路由器、交换机，服务器和网关。网络可包括一个或多个连接的网络(例如，多网络环境)，包括诸如因特网之类的公共网络，和/或诸如安全企业专用网络之类的专用网络。可以通过一个或多个有线或无线接入网络来提供对网络的接入，如本领域的技术人员将理解的。

内容访问服务100可包括导入/转换部分102和渲染/转换部分104。来自各个源106的文档可被导入到内容访问服务100。导入/转换部分102可通过减少或移除对将内容变为阅读器需要的特定格式的约束来促进自发布。例如，自发布到书店或其他储存库或商店可在不需要创建者在指定文件格式内工作来实现。通过使创建者更为容易地发布他们的作品，阅读器用户可访问更多的内容。

“阅读器”指主要出于阅读电子书(ebook)和/或其他电子内容的目的而设计的软件应用和/或电子设备。阅读器通常包括至少一些基本编辑能力，诸如注释、突出显示、书签以及划线。

示例软件电子书阅读器(或电子阅读器)包括来自谷歌公司的GOOGLE READER应用、来自苹果公司的APPLE IBOOKS应用、来自奥多比系统公司的ADOBE ACROBAT EBOOKREADER应用以及来自微软公司的MICROSOFT READER应用。示例硬件电子书阅读器(或电子阅读器)包括来自亚马逊公司的AMAZON KINDLE品牌电子阅读器以及可从巴诺书店公司得到的BARNES AND NOBLE NOOK品牌电子阅读器平板。电子书是可被在电子书阅读器上读取的具有数字形式的基于文本和/或图像的发布。存在用于创建和发布内容的各种电子书和其他数字内容格式，诸如电子发布(ePub)、HTML、PDF、打印机命令语言(PCL)以及可扩展标记语言(XML)。

在一些情况下，(例如，通过导入/转换部分102)导入的文档可被存储或看上去被存储(通过将地址或统一资源标识符存储)为云的一部分(108)。内容访问服务100可解析存储108上的操作或将某些操作委派到另一服务(其可直接或间接地访问存储108)。

文档文件可从内容访问服务100中导出。在被导出之前，文档文件(诸如被导入的文档之一)可被转换成各种格式以供端点(诸如阅读器110、打印机112、第三方站点114和辅助转换服务116)消费(例如，渲染以供显示、交互、修改或包括打印和进一步转换的附加动作)。

端点指的是消费者藉此访问服务的装置——用于交互的入口点。根据各个实施例，提供端点定制，其扩展了可达范围并改变了内容基于设备被消费的方式。

端点可以是一个或多个消费者设备。

消费者设备指被用于消费(即，用于查看/阅读、编辑或注释)从服务或源检索的或购买的数据或文档的计算设备。消费者设备可以主要是用于阅读电子书的单用途计算设备(通常称为阅读器)或在其上可提供用于阅读电子书或其他电子/数字内容的阅读器或查看器软件的多用途计算设备。

“查看器”指能显示或看上去显示具有与特定程序相关联的格式或文件类型的文档或数据的软件或硬件应用。针对特定文件格式的查看器能够理解该特定文件格式并呈现该文件的可视化。通常，文件格式的“查看器”被假定为能够用高保真度来在视觉上呈现该文件格式，从而维持作者的原始意图。“阅读器”是包括主要与“阅读”体验相关联的功能(诸如提供动画化的翻页、记住最后阅读位置、提供字典来查找单词等)的一种类型的查看器。

服务扩展文档的可达范围(到跨各种平台的设备)并创建针对该文档的适合于客户端设备的体验。文档不需要在每个客户端上看上去完全相同。相反，文档可针对用户的体验并适合设备来被定制。

通过知晓设备，系统(例如，通过服务100)可提供定制的文件格式化。

作为一个示例场景，NOOK阅读器或KINDLE阅读器用户可使用该设备来浏览可用内容来阅读。服务100可确定什么设备正被使用并适当地定制内容的呈现。例如，ePub2或ePub3格式可被发送到NOOK阅读器而AZW格式可被发送到KINDLE阅读器。

一旦定制的文件被发送到设备，该文件就可被保存回服务器(经由服务100)。例如，可相对于提供到客户端的文件采取特定动作(修改，诸如在NOOK阅读器、KINDLE阅读器或运行编辑器应用的平板内注释或编辑)，并且这些修改被合并到该文件的主文档。

在其他实施例中，还通过知晓用户(例如，通过接收来自用户的标识符，诸如当用户从设备登录到他们的帐户时)，系统(例如，通过服务100)还可使得用户能够通过网络在许多设备上访问他们自己的文件，而无需用户必须考虑他们的设备能处理的版本或文件格式。除了使得用户能够访问他们自己的文件外，通过知晓用户，系统还能定制文件以呈现文档中与关联于用户的任务有关的特定内容。例如，在用户具有审阅一段落的任务的情况下，该段落可被提供给所标识的用户而非能访问文档的所有用户。

端点可具有与服务100通信的两种一般分类。一种是双向丰富体验，而另一种是更受限的体验。在这两种情况下，通过使用本发明的各实施例，端点不被要求处理文件格式转换、能够渲染所有格式或包括用于内容的共同创作的层。

各种丰富性的端点可被本发明的各实施例支持。如本文中使用的，“丰富性”指使用一应用的可用体验的范围以及该应用的向用户呈现特定内容和功能的能力。例如，最丰富的消费体验可通过支持其中内容的编辑和操纵可用的全特征应用(例如，端点编辑器118)的设备可用。更受限的体验包括其中用于内容的编辑和操纵的某些功能被维持的很小的创作工具(例如，受限的端点编辑器120)。更受限的体验(或“轻量编辑”)和全特征编辑器(或“重编辑”)之间的区别是轻量编辑可仅支持注释和评论。

其中内容可被查阅的阅读器(例如，消费者设备122)可具有支持的丰富性的范围。所有编辑器类型以及特征的各版本可被支持。

访问服务100提供的转换和合并服务可由客户端设备或另一服务器(例如，阅读器110或消费设备122、端点编辑器118或消费和受限端点编辑器120)直接请求。在一些实施例中，服务器(诸如参考图2描述的)或第三方站点(例如，114)或辅助转换服务(例如，116)可代表客户端设备来访问服务100。打印机112还可直接或通过另一客户端设备接收来自转换和合并服务100的内容。

端点编辑器118藉此可与web服务(例如，服务100)通信的一个框架是经由以下框架：该框架允许客户端应用使用FSSHTTP应用编程接口(API)来有效地同步对文档以及运行在服务器上的文件管理和协作程序(诸如MICROSOFT SHAREPOINT web应用平台)的改变。FSSHTTP协议的客户端侧是直通(pass-through)。例如，由较高层协议(诸如应用层)作出的调用被直接传递到传输层，并且从传输层返回的结果被直接传递回较高层协议或应用。

API一般是用于使得两个或更多个应用能够相互通信的编程指令和标准的集合并且通常被实现为HTTP请求消息的集合和用于响应消息的特定格式或结构。消息可包括信息资源。资源是可通过统一资源标识符(URI)标识的信息并可以是文件、动态生成的查询结果、通用网关接口(CGI)脚本的输出、以若干种语言可用的文档等。

转换和合并服务100可与更宽泛的云服务130以及web应用组件(WAC)132相关联。WAC是使得用户能够在浏览器中查看和编辑文档的组件。WAC既可通过消费和编辑内容来用作端点，也可通过提供某个合并和转换服务功能来用作服务。在这样的实施例中，用户能访问云上的应用软件和数据库，其管理基础设施和平台。终端用户通过浏览器或应用(针对诸如智能电话和平板等移动设备设计的应用)来访问被托管在云上的软件应用。参考图2描述了一示例。

图2显示了根据本发明的一实施例的端点的操作环境。参考图2，客户端210和服务器220经由网络230通信。

网络230可以是互联网、内联网或外联网，并且可以是任何合适的通信网络，包括但不限于，蜂窝(例如，无线电话)网络、因特网、局域网(LAN)、广域网(WAN)、WiFi网络、自组织网络或它们的组合。

如之前描述的，这样的网络可涉及网络元素(诸如集线器、桥接器、路由器、交换机、服务器以及网关)的连接。网络230可包括一个或多个连接的网络(例如，多网络环境)，包括诸如因特网之类的公共网络，和/或诸如安全企业专用网络之类的专用网络。可以通过一个或多个有线或无线接入网络(未示出)来提供对网络230的接入，如本领域的技术人员将理解的。

客户端210和服务器220可包括配备有一个或多个中央处理单元(CPU)、存储器、大容量存储和I/O设备(例如，网络接口、用户输入设备)的计算系统。计算系统的元素可经由总线相互通信。计算系统的硬件平台可被体现为多种形式，包括但不限于，个人计算机、服务器计算机、手持式或膝上型设备、多处理器系统、基于微处理器的系统、可编程消费者电子设备以及包括以上系统或设备中的任意系统或设备的分布式计算环境(例如，基于云的计算系统)(并且其中应用功能、存储器、数据存储和检索以及各种处理功能可通过分布式计算网络(诸如因特网或内联网)彼此远程地操作)。

在某些实施例中，客户端210可被体现为计算设备，包括但不限于，个人计算机、平板、阅读器、移动设备、个人数字助理(PDA)、智能电话、膝上型(或笔记本或上网本)计算机、游戏设备或控制台、台式计算机或智能电视机。

在某些实施例中，服务器220可被体现为计算设备，包括但不限于，服务器计算机、企业计算机、个人计算机、多处理器系统、基于微处理器的系统以及它们的组合。应当理解，客户端计算设备和服务器计算设备的列表不旨在限制并且客户端和服务器可用相同或不同的形式体现。

客户端计算机210被配置成执行操作系统211和一个或多个应用程序，诸如在所示实施例中，文字处理或编辑器应用212、web浏览器应用213、和/或一个或多个其他应用。

操作系统211是用于控制客户端计算设备210的操作的计算机程序。应用程序是被配置成在操作系统211之上执行以提供诸如本文所述的各种功能的可执行程序。文字处理应用是通常被配置成促进键入、编辑、格式化、保存、打印和评论的应用程序。编辑器应用可以是提供编辑或注释工具的任意应用并可以是文字处理应用或其他生产力应用，诸如从微软公司可用的MICROSOFT OFFICE，从谷歌公司可用的GOOGLE DOCS，从阿帕奇软件基金会可用的APACHE OPENOFFICE或从卓豪公司可用的ZOHO OFFICE。

生产力应用包括但不限于，文字处理程序、协作程序、演示程序、电子表格程序以及讲故事/做笔记程序。

web浏览器应用213是用于检索和遍历万维网(“web”)上的信息资源以及由专用网络中的web服务器经由网络230提供的资源并向用户呈现信息资源(例如，渲染以供显示)的应用程序。此外，web浏览器应用213允许用户访问服务器提供的信息和各种功能。

所示服务器计算机220被配置成执行服务器操作系统221、一个或多个应用程序(诸如服务器文字处理或编辑器应用222)、和/或一个或多个其他应用。服务器220还可主控服务(并合并WAC 132(诸如图1中描述的))。

服务器操作系统221是用于控制服务器计算机220的操作的计算机程序，并且应用程序是被配置为在服务器操作系统221之上执行以提供本文中描述的各种功能的可执行程序。在一些实施例中，服务器文字处理或编辑器应用222是与以上描述的文字处理或编辑器应用212类似配置的基于web的应用程序。服务器文字处理或编辑器应用222可提供与文字处理或编辑器应用212相同的功能。

在一些实施例中，服务器计算机220被配置成执行服务器文字处理或编辑器222，并且客户端计算设备210被配置成访问服务器计算机220来按照客户端/服务器配置与服务器文字处理或编辑器应用222交互。

客户端-服务器关系下的计算设备之间的通信可以通过由客户端向服务器发送要求访问特定资源或执行特定工作的请求来发起。服务器随后可以执行所请求的动作并且将响应发送回客户端。

在一个实施例中，客户端web浏览器应用213被用于与服务器(例如服务器220)连接以访问基于web的文字处理或编辑器应用122。

客户端210和服务器220可通过网络230访问转换和合并服务240。在客户端210和服务器220上运行的应用可经由普遍存在的web协议和数据格式(诸如HTTP、XML、JSON和SOAP)或经由FSSHTTP协议来访问服务240。

图3显示了根据本发明的一实施例的计算环境。如图3中示出的，用户300的计算环境可包括多个客户端(诸如台式计算机311、膝上型计算机312、智能电话313、平板314、阅读器(未显示)、游戏控制台(未显示)、智能电视机(未显示)等)以及通过网络330连接的服务器320。

如以上关于图2的网络230描述的，网络230可以是互联网、内联网或外联网，并且可以是任何合适的通信网络，包括但不限于，蜂窝(例如，无线电话)网络、因特网、局域网(LAN)、广域网(WAN)、WiFi网络、自组织网络或它们的组合。

(诸)客户端310和服务器320可包括被配置的计算系统，诸如关于客户端220和服务器230描述的。

每个客户端310可包括用于查看和编辑(和/或注释)由服务器320通过内容访问服务提供的文档(以及其内容)340的软件应用。

用户300可具有多个客户端310(例如，办公室中的台式计算机311、家里的膝上型计算机312以及移动电话/智能电话313)，并可使用在这些客户端310上运行的软件电子书阅读器或文档查看器或编辑器来阅读从服务器320检索的电子书和其他数字内容以及编辑和/或注释该内容。

服务器320是被配置成提供(作为内容访问服务的一部分)转换服务和合并服务的硬件设备和/或软件程序。转换服务使得用户能够访问可以具有不直接被用户正在使用来访问内容的特定客户端310支持的文件格式的内容(甚至是用户自己的内容)；并且合并服务将用户300作出的改变重新整合到存储在数据库350中的主文档345。

服务器320提供的服务(或功能)中的一个或多个可在云计算环境中执行。此外，服务器320可包括通过API展示的应用(和/或主控服务)。

根据某些实施例，包括服务器320的、能从客户端310或数据库(诸如数据库350)导入文档的系统可被提供。导入的文档可被认为是主文档345，或主文档345可从导入的文档中创建并被存储在例如与服务器320相关联的数据库350中。

服务器320可将文档345转换成适用于消费者设备(例如，台式计算机311、膝上型计算机312、智能电话313、平板314、阅读器(未显示)、游戏控制台(未显示)等)的格式。

用户300可跨每个设备(例如，311、312、313、314)访问主文档345的合适版本(例如，具有文档340的形式)。例如，文档340可跨任意设备和平台呈现。例如，在膝上型计算机312上在一个程序内对文档340进行操作的用户300可保存具有这些改变的文档。保存文档可调用合并服务。例如，如图5B-5D中显示的，整个文档(图5B)、改变(增量)(图5C)或特定修改(图5D)可被返回到服务器以供与主文档合并。

实际的物理文件可被或可不被存储在云中(作为云存储——诸如数据库350——的一部分)。文件可被存储在可通过网络被服务访问的服务器或计算机或任意存储位置上。主文档(或其他导入的文件)可被存储在服务器320处作为可寻址文件的集合，其可在请求之际被导入并转换。

客户端设备(诸如膝上型计算机316)上的另一用户360或第二设备(诸如平板314)上的第一用户300可打开文档340，并且他们的体验是文档340是可在设备316(或在其上第一用户300访问文档的第二设备314)内操作的文档。使用设备316的第二用户360(或第二设备上的第一用户300)接着可在编辑后保存该文档并且服务将合并改变。

根据各实施例，每个客户端310都认为它具有以针对该客户端而言适当格式存储的文件。没有必要在客户端处改变文件以便打开文件和访问数据。例如，应用可依然如期望地打开文档——服务器负责客户端是否接收合适的文件格式。在客户端310处，用户(300，360)根据预期的过程来打开、改变并保存文档。服务器理解端点的限制并向设备提供适当的格式。

服务器320和消费者/客户端设备310通信，使得系统知晓在客户端310上什么类型的设备或软件可用并相应地定制用户的体验。

服务器320可被配置成标识端点处的用户代理/客户端特征。该标识可基于从端点(例如，客户端310)发送到服务器320的主动或隐式通知。服务器320还可被配置成定制客户端体验以及持久保存的体验(例如，主文档的存储的副本)。

根据某些实施例，提供的文档340不仅被重新流化以适应更小(或更大)的显示器大小，还可作出附加的调节。

重新流化指针对受限的显示器或窗口对查看内容的调节，其中文本可被保留在其原始大小以容易阅读，而图像在大小上减小，使得它们可一眼被查看。

作为附加调节的一个示例，高分辨率设备可被提供高分辨率内容(较高的形状因子可接收较多对象)，而电话可接收较低分辨率的图像(而非例如文档中图片的12百万像素版本)。此外，启用触摸的设备可具有添加到文档的触摸响应特征。还可提供(例如，通过API展示的)其他定制的端点服务，包括但不限于，使得能够在文档上注释和添加工作流元素(诸如待作项)的那些服务。安全性设置和权限管理也可针对客户端来定制。例如，当较旧的版本或某些文件格式被提供给客户端时，文档可被提供来以只读操作以最小化以较低保真度版本保存的破坏性，但允许文档被保存——作为与主文档不同的副本。

不仅提供的文档340具有适用于(或甚至被定制)由特定消费者设备渲染的格式，而且对于文档340的修改可与主文档345重新整合。服务器320可通过知晓什么类型的设备和/或软件在客户端处可用来重新整合修改。例如，在客户端设备使用不同平台(以及文件格式)的情况下，服务器320可知晓可在转换中丢失的保真度并在服务器上重建回任何改变。

类似地，在客户端设备使用特征的不同版本时，服务器340可知晓所使用的版本并相应地调整。特征包括但不限于，用于操纵和编辑文本、图表、方程、文本效果和图形(包括MICROSOFT SMARTART图形)、数字内容(包括视频)、目录样式、线程化评论、拼写检查、字典、语言的实用工具以及用于操纵和编辑图形的实用工具。

服务可提供向后和向前兼容性。

例如，MICROSOFT WORD的最新版本的文档可被提供给运行MICROSOFT WORD的较早版本的客户端，而无需客户端必须执行到该较早版本的转换。此外，并非提供只读版本(以避免保存回较低保真度版本产生的问题)，运行该较早版本的客户端可编辑文档，这是因为知晓该较早版本如何破化全保真度版本(以及替换高保真度内容的图像表示什么)的服务器可在服务器上重建回数据(即，执行保真度再融合(rehydration))。

保真度再融合可在服务器处执行，这是因为服务器知晓内容被提供的形式以及可在文件具有特定文件格式时关于文件实现的特定约束和动作。

图4显示了根据本发明的一实施例的用于转换和合并服务的示例过程流。参考图4，在操作(402)，当服务器接收合并请求时，可提供该请求和文档。服务器可确定文档是新文档还是存在于系统上(404)。如果文档是新文档(或新副本)，则系统可根据该文档创建主文档(406)。主文档可以是该文档(使用相同的文件格式和特征版本)或主文档可通过将该文档转换成特定文件格式和特征版本来创建。

通过创建主文档，某些实施例可创建针对用户的文档即服务体验。具体而言，主文档包括由主文档连同创建者和其他人可关于该文档采取的动作的集合组成的内容。定制的体验可被提供给消费者并且编辑内容的能力可被展示为服务的一部分。

返回到操作(404)，如果文档被确定为不是新文档(例如，因为主文档已经存在于系统上)，则服务器可确定该文档是具有与主文档相同的文件格式还是不同的文件格式(408)。响应于确定文件格式是不同的，服务器可将该文档的文件格式转换成主文档的文件格式或系统理解的某一其他格式(410)并接着自动地确定该文档和主文档之间的区别(412)并合并区别(增量)来更新主文档(414)。将增量合并到主文档中使得在一个设备处的用户能够对文档采取些操作并具有与该文档相关联的改变，使得访问该文档的下一人(或第二设备上的同一人)看到那些改变被反映在该第二人(或第二设备)接收到的文档上。

返回到操作(408)，如果文件格式是相同的，可作出关于该文档支持的特征版本是否与主文档支持的特征版本相同的确定(416)。响应于确定特征版本是不同的，服务器可确定该文档和主文档之间与非特征有关的区别(增量)(418)并使用所确定的增量来在不丢失保真度的情况下更新主文档(420)。

通过确定文件格式和/或特征版本，整个文件以及文件内的内容可被分析以便将一个文档变换成另一文档或将内容从一个版本变换成另一版本。在该文档和主文档之间的文件格式和特征版本之间没有区别的情况下，区别可自动地在主文档处被更新(422)或主文档可被该文档替换。

图5A-5D示出了转换和合并服务的示例场景。参考图5A，转换服务505可访问来自数据库510的文档并向客户端以支持的文件格式来提供该文档，例如作为所显示的文档520。所显示的文档520的内容的实际格式(如存储在数据库510中的)可包括但不限于，PDF、DOC、DOCX和ePub；然而，转换服务505可用客户端支持的——并且甚至为端点定制的——格式来提供内容。

各实施例提供一系统，其中文档以好像它们具有特定客户端所需的格式那样呈现给用户——即使文档实际上不以该格式或版本存在，直到用户选择该文档来查看(或编辑)。替代于将存储在服务器上的所有文件预先转换成每种类型的文件格式，文档的特定格式在用户请求之际被递送。

各实施例可扩展其中内容可被消费的可达范围并为该内容创建适合于在其上内容被提供的设备(或客户端)的体验。服务器可解释设备和能力以确定什么是用于在特定设备上查看内容的理想或合适的方式。服务可考虑在内的特征包括但不限于，显示器的尺寸、设备的用户输入能力、网络连接的速度和/或带宽以及操作系统和应用约束。

例如，一些文档可能显示在膝上型计算机上看上去不错，但是在较小的屏幕上(诸如在电话或平板上)不那么有用。通过确定客户端是什么(诸如确定适用于该客户端的消费格式)，服务基于设备(或软件)来修改消费体验。

在客户端，服务505提供的文档520可被编辑。在当前示例中，经编辑的文档525可被合并回主文档以促进跨不同编辑器和特征版本的协作。为了提供合并服务，可使用用于协作和合并服务的一通用API或多个API。API使得客户端能够跨多个平台合并对文档的改变。此外，服务可在以下情况中扩展到第三方适配器：其中可发生到可识别文件格式的中间转换，例如在专用或新格式被开发的情况下。

图5B-5D显示将经编辑的文档525合并回主文档的各种场景。

图5B显示其中具有修改的整个文档530被提供到合并服务540的情况。参考图5B，可使用一通用API。在一个实施例中，客户端可将整个文档与改变(作为文档530)向上发送到服务器(例如，服务540)。服务530解释文档530，确定区别并接着自动地合并。即使经编辑的文档具有与主文档不同的文件格式，合并依然可实现。文档530可被服务540转换成特定格式以促进合并。

图5C显示了其中文档520和经编辑的文档525之间的区别(增量550)(经由通用API)被提供给合并服务560的情况。服务560解释增量550并自动地合并。即使经编辑的文档具有与主文档不同的文件格式，合并依然可实现。

图5D显示了其中多个API被使用的情况。API可被捆绑来作为用于合并内容的轻量选项的一部分。API可以是各单独的修改功能并可包括但不限于，突出显示API、字体API、段落API、样式API、翻译API、公式API、表格创建和编辑API；图像插入、创建或编辑API；颜色API、评论API等。API中的一个或多个可对特定客户端可用。

例如，客户端可调用突出显示API并传递段落标识符或文本，并且服务执行突出显示。客户端可调用评论API并提供评论要被插入在其中的句子、段落或单词以及要插入作为评论的文本。设备不需要理解文档的文件格式。例如，文档可被存储为DOCX文件，但是客户端将文档作为PDF文件或ePUB文件来查看(和编辑)。

根据另一实施例，客户端可调用评论API，其可提供评论服务。评论服务(经由例如评论API)可使得受限端点能够将文档的各部分上的评论发送到服务中以供合并到完整文档中。评论服务可接收评论以及关于评论与文档的什么部分相关联的指示并接着修改完整文档以包括评论。

在图5D中显示的示例中，经编辑的文档包括第一段落的突出显示、对第三段落中的文本的修正以及添加到与文档相关联的元数据的签名。对于突出显示API，客户端可调用突出显示API并将段落标识符570传递到突出显示服务575。为了修正打字错误，客户端可将位置标识符(例如，第三段落、第一句)和替换文本580传递到文本编辑服务585。为了添加签名，客户端可将位置标识符(例如，元数据)和签名590传递到签名服务595。

位置标识符可包括但不限于，标识文档中的段落的段落标识符、标识文档中的行的行标识符、标识文档中的字符的字符标识符以及标识文档的一部分的部分标识符。部分标识符可提供在文档的各部分(诸如文档内容、评论内容、样式内容等)之间进行区分的位置标识。由部分标识符标识的文档的各部分还可以是文档内结构上描绘的内容。在一个实施例中，部分标识符标识文档的通过具有相关联的元数据的结构化标记来修改的部分。结构化描绘的内容的一个示例如下：

This is a paragraph.(这是一个段落。)

<fill-in region(填充区域)>Here is some content that a user may edit

and then send back to the server to merge(这里是一些用户可编辑并接着发送回服务器来合并的内容)</fill-in region(/填充区域)>

Following paragraph.(下一段落。)

在以上示例中，其具有内容控件的外观，可被用户修改的内容位于标识的“fill-in region(填充区域)”标记之间的段落中。在一些实施例中，可通过文档中的结构化标记(例如“fill-in region(填充区域)”)来标识文档中要发生修改的部分。

在一些实施例中，来自支持纯文本文件格式的客户端的内容可通过递送文本并调用能取得文本并添加指定格式化的API的服务来将丰富内容添加到文件。类似地，内容可通过调用添加内容到元数据的服务来被添加到元数据。

图6显示了根据本发明的一实施例的由编辑器实现的过程的示图。编辑器指包括用于编辑文本、图像或声音的工具的客户端(硬件或软件)。编辑器可以是生产力应用，包括文字处理应用。

参考图6，在操作(602)，编辑器可请求文档。请求可以是打开位于云数据库604上的文件。由于文档可能不具有与编辑器支持的文件格式相同的文件格式，对于文档的请求可调用提供转换服务的访问服务608。访问服务608可从数据库604中检索文档并将文档转换成对于编辑器而言合适的文件格式。在操作(608)，编辑器可从访问服务606接收经转换的文档并渲染接收到的文档以供显示。

从数据库604中检索的文档可以是主文档。在使用编辑器的过程期间，用户可修改接收到的文档。当对接收到的文档作出修改时(610)，修改可通过调用合并服务被合并到主文档中(612)。

调用合并服务(612)调用访问服务614的合并服务。对合并服务的调用可作为对从用户接收到保存命令的响应来发生。在另一实施例中，对合并服务的调用可作为工作流的一部分来发生。例如，对合并服务的调用可通过特定事件(诸如来自系统的自动保存)来触发。

任选地，确认过程(616、618)可被包括以基于用户的标识提供对于文档和/或访问服务的访问。例如，OATH令牌可被用于针对访问服务(606、614)来确认登录的用户。令牌可由编辑器发送到云数据库和/或访问服务，使得用户可被认证并且文档可被访问。

其他实施例可利用身份管理器来便于服务知晓用户是谁以及用户关注什么文档。通过知晓用户的身份，服务可代表用户来跨多个设备(例如，用户的计算机、膝上型计算机、平板、智能电话、电子书阅读器等)和服务(例如，文件主控服务，诸如来自Dropbox公司的DROPBOX服务以及来自微软公司的MICROSOFT SKYDRIVE服务)检索用户的内容(例如，文档)。

此外，通过知晓文档在其上被提供的客户端，系统可取得具有一种格式的文档并将该文档转换成针对正被用户使用的客户端定制的格式。例如，用户可正在MICROSOFTWORD中对一文档进行操作并想要在她的电子书阅读器上访问该文档。在一种这样的情况下，当用户从她的电子书阅读器中浏览可用的文件时，服务可向用户呈现该文档(例如，所以用户能在电子书阅读器上阅读它)。这可移除用户目前采取的将文档发送到电子书阅读器(以便将文档转换成适当的格式)的步骤。

文件可在在阅读器设备上打开应用之际可用。应用可具有能在阅读器上运行的相关联的文档中枢。在另一实施例中，阅读器提供的服务(诸如由亚马逊公司为Kindle阅读器提供的)可经由可扩展性层来集成用户的体验，以使得它们的用户能从本发明的某些实施例的访问服务中访问文档。

根据一实施例，用户可简单地对文档操作，保存文档(或文档的地址)并关闭文件。通过知晓用户是谁以及接着文档要对什么平台可用的身份管理器，当被相同或不同客户端再次访问时，文档将以适当的格式存在以供用户访问。

图7显示了根据本发明的一实施例的用于使用多个编辑器在文档上协作的方法的过程流图。协作的方法可基于被访问服务管理的主文档700。第一编辑器(编辑器1)可在操作(710)向访问服务请求文档700。主文档700可被存储在与访问服务相关联的数据库中或由访问服务从已知的位置中检索。在这个示例中，第一编辑器可以是支持ePub格式的阅读器并且主文档具有DOCX格式。访问服务可确定用于第一编辑器的合适的格式(715)并将文档提供给第一编辑器(720)。由于第一编辑器支持ePub格式而不是主文档的DOCX格式，所以服务可以用ePub格式向第一编辑器提供文档。

第一编辑器可接收ePub格式文档(725)并显示文档(730)。第一编辑器的用户可例如通过包括评论来修改ePub文档(730)。当保存命令(或其他指定情况)发生时，第一编辑器可向访问服务请求合并(740)。请求可包括具有修改的整个ePub文档(例如，文档和评论)或修改的位置标识符以及修改(例如，评论的位置以及要作为评论被添加的文本)。

访问服务可接收合并请求(745)并执行操作来将修改合并到主文档(750)。主文档可保留在其原始格式和版本。

第二编辑器可向访问服务请求文档(755)。在这个示例中，第二编辑器可以是支持DOCX文件扩展名、但处于与主文档的特征版本不同的特征版本的计算设备。作为说明性示例，主文档可以处于版本5，但第二编辑器可处于版本1。移至操作(760)，访问服务可确定用于第二编辑器的合适的格式，并将文档提供到第二编辑器(765)。第二编辑器可接收DOCX(特征版本1)格式文档(770)并显示文档(775)。第二编辑器的用户可修改文档(780)。当保存命令(或其他指定情况)发生时，第一编辑器可向访问服务请求合并(785)。

访问服务可接收合并请求(790)并执行操作来将修改合并到主文档(795)。修改可以是针对使用两个版本均支持的特征的内容的一部分。由于第二编辑器支持DOCX的较老版本而不是较新版本，到较新版本的保真度再融合可通过使用服务来实现——并且使用较新特征的内容将不被合并破坏。

如果修改是针对使用不被两个版本均支持的特征的内容的一部分，则可通过包括代表用户作出的改变以及响应于用户作出的决定来作出的改变的任何合适的方式来解决冲突。例如，在一些情况下，服务作出的决定可关于如何、何处以及是否合并修改来作出。对于其中决定不能(或没被达成)来作出决定的情况下，服务可向一个或多个设备提供查看所有冲突和可能性的选项。用户可接着选择用于解决冲突的选项。

访问服务使得多个编辑器能查看和编辑同一文件。此外，第二编辑器和第一编辑器两者在访问主文档时跨不同的平台访问文档。

以下示例场景被呈现来提供对于本发明的某些实施例以及其许多益处的更好的理解。以下示例场景仅仅用于说明本发明的实施例的应用和变型中的一些。当然，它们不以任何限制本发明的方式被考虑。

示例场景A：

KINDLE阅读器或NOOK阅读器的用户正在阅读文档并想要对文档作出贡献——要么通过评论、修正打字错误、突出显示，要么通过执行某个其他修改或注释。这些阅读器可具有一些编辑能力——即使阅读器主要不是编辑器。因此，本发明的某些实施例允许用户利用阅读器的能力(例如，注释和编辑能力)并接着将这些修改合并回文档中。替代于每个设备或应用必须包含共同创作能力，“文档即服务”合并服务可自动地将编辑/内容合并回文档中——即使来自不同的平台。

在一个实施例中，当阅读器执行同步操作(诸如被用于使得用户能够在从所能达到的最远位置中拾取数字内容的同时跨多个设备阅读电子内容)时，合并可被实现。在一个这样的情况中，在对针对同步服务更新位置的调用期间，对文档的修改可被发送到本发明的一实施例的转换和合并服务。

在另一实施例中，阅读器可在用户作出主动步骤之际(例如当用户选择保存文档时)调用转换和合并服务。在又一实施例中，自动保存特征可被用于保存改变。

由于客户端不被要求包括能理解并执行共同创作的层，因此设备可以是“哑的”或将设备资源集中到其他应用和功能。

示例场景B：

文档可被创建为具有针对从微软公司可用的MICROSOFT WORD文档和文字处理软件的最近版本的DOCX格式，但是创作者想要在阅读器上查看并且可能评论或编辑该文档，该阅读器诸如可使用ePub文件格式的NOOK阅读器或可使用专用AZW和KF8格式的AMAZONKINDLE阅读器。通过使用服务，该人能以针对NOOK阅读器或KINDLE阅读器而言适当的格式访问文档并接着通过例如添加一些评论来对文档作出改变。评论可被保存回主文件，在这个情况下是DOCX文件格式。

示例场景C：

当前，在与被用于创建MICROSOFT WORD文档的版本不同的版本中打开MICROSOFTWORD文档文件可导致该文档没有显示所有特征。例如，某些字体和格式化可改变并且丰富或复杂特征可消失，例如脚注能力和一些宏。在一些情况下，版本方面的改变也是文件格式方面的改变，诸如在使用MICROSOFT WORD 97(其使用DOC文件格式扩展名)和MICROSOFTWORD 2010(其使用DOCX文件格式扩展名)的情况下。在其他情况下，版本方面的改变提供附加的功能和/或特征，诸如在使用MICROSOFT WORD 2007和MICROSOFT WORD 2010的情况下。

当文档在较老版本中创建并接着在较新版本中打开时，较少的问题会出现，但是依然存在其中特征在较高版本中被逐步淘汰或不被完全支持的错误。除了显示在与被用于打开文档的版本不同的版本中创建的文档所发生的问题之外，当在较高版本中创建的文档在较早的版本中被打开和保存时，较高版本特征可能丢失——即使在文档在较高版本中被重新打开时。例如，MICROSOFT WORD 2010文字处理应用包括用于创建和操纵图形的特征。如果文档在MICROSOFT WORD 2010中被创建为具有精美的图形，但在MICROSOFT WORD 97中被打开以修正在文档的第一页上的一些文本中的打字错误并接着被保存，则所保存的文档回复到较老版本(具有文件格式扩展名DOC)——从而丢失了精美的图形。仅仅是因为一个单词给改变，整个文档就回复到图形图像的较老版本。

根据某些实施例，用户在较老版本中的有意改变可按保留较新特征的方式被识别并合并到新版本支持的文档中。

示例场景D：

通过使用内容访问服务，内容可针对现有产品的较老版本来定制。例如，用户可以能够延迟到软件应用的最新版本的升级或要求下一版本可向后兼容以便读取较老/较新文件格式扩展名，这是因为用户(运行最新程序并反之亦然)会接收到的文件可基于端点来定制。

例如，运行MICROSOFT OFFICE 2013的客户端可要求具有所有可用特征的完整视图，但是当同一文档从运行MICROSOFT OFFICE 2007的客户端打开时，服务可针对消费视图来打包内容、但针对MICROSOFT OFFICE 2007来优化。优化可包括将某些特征用具有适当保真度的那些来替换。作为一个示例，在一个版本中提供的公式编辑器可能不是向后兼容的。因此，服务可将文档包中的公式用公式的图像或可在适合于其中文档被提供的版本的公式编辑器中编辑的形式来替换。

类似的体验可针对其他生产力应用(包括文字处理应用)来提供。例如，运行MICROSOFT OFFICE 2013的客户端可接收具有所有可用特征的完整视图，但是当同一文档从运行另一生产力应用(诸如从谷歌公司可用的GOOGLE DOCS、从阿帕奇软件基金会可用的APACHE OPENOFFICE或从卓豪公司可用的ZOHO OFFICE)的客户端中打开时，服务可针对消费视图来打包内容、但针对GOOGLE DOCS、OPENOFFICE或ZOHO OFFICE来优化。

示例场景E：

主文件可以用最高保真度格式来存储。例如，主文档可被存储为MICROSOFT WORD的最近版本。运行MICROSOFT WORD的较早版本的客户端可被提供具有DOC格式而非DOCX格式的文件。当用户对DOC文档作出改变并保存文档(要么作为自动保存的一部分要么通过主动步骤)时，对DOC文档的改变可被保存回具有DOCX格式的主文件中。在一个实施例中，整个DOC文档在服务器处被再融合成DOCX格式。在另一实施例中，只有被用户修改的部分(并且不简单的是当将DOC文件提供到客户端时对内容作出的区别的部分)在保存之际被返回到服务器。这个部分可接着与全保真度文档重新关联。

示例场景F：

各实施例可促进相同产品的不同版本之间的向前和向后兼容性。当前，保存在MICROSOFT WORD程序中的文件可针对多个目标来保存。例如，当用于公式的经更新的特征版本被用在文件中并且文件被保存时，本机公式数据被保存出(使得它可用适当的保真度来读回以供编辑)并且公式的图片被保存出，使得文字处理器的先前版本显示公式看上去什么样——即使公式编辑器不被支持。较老版本可包括关于如何让较新版本取回它的全保真度的信息。例如，较老版本可处于显示模式并不允许编辑。

文字处理器的每个版本都包含关于如何往返某个特征的信息，使得特征版本可取回它的全保真度。往返指文档从一个版本去往另一个版本并接着返回到原始版本。例如，特征A可在版本X中、但不在版本Y中，特征A可被表示为特征A-主(A-prime)。当特征A-主从版本X被查看或访问时，特征回到A。这种安排对将来版本施加压力以基于较早版本如何能往返特征(以及可能要求附加的数据被保存)来创建向下兼容性。

本发明的各实施例移除或最小化对于使版本知晓如何往返各个特征的压力以及减少被保存来支持多个版本的数据量。各实施例使得产品的较老版本能阅读并保存来自产品的新版本的内容。

示例场景G：

丰富文本格式(RTF)是对各个文档、文本和图形格式化属性进行编码以用作适用于多个文字处理应用的跨平台文档交换的文件格式。当前，RTF文件保存文件中图片的多个单独版本以支持该文件的潜在客户端/消费者。例如，一个文件提供该图片的当前版本，第二(或更多)文件提供该图片的一个或多个先前版本，另一文件提供WORD 2.0版本，并且又一文件提供WORDPAD版本。通过提供转换和合并服务，文字处理应用不需要支持多个文件格式或具有同一内容的多个文件。

示例场景H：

合并服务可被应用来自动地在已经被电子邮件发送的文档内合并改变。在这样的情况下，电子邮件服务或服务器可与合并服务通信。合并服务可就像电子邮件服务(或电子邮件服务器)是编辑器那样来管理合并。

例如，一群人可在文档上协作。该群中的一人可将该人离线作出的改变用电子邮件作为电子邮件的附件发送到其他人。知晓该文档的标识符的服务和系统可代表用户通过用电子邮件发送到其电子邮件服务或电子邮件服务器被配置成与合并服务通信的收件人的动作来自动地将改变合并到主文档。

在另一示例中，该群人中的一人可使用与第一电子邮件服务相关联的电子邮件帐户来向其他人发送电子邮件并添加加该文档作为附件。收件人中的一些可使用不连接到第一电子邮件服务的第二电子邮件服务。例如，第一电子邮件服务可以是来自微软公司的HOTMAIL电子邮件服务，而第二电子邮件服务可以是来自谷歌公司的GMAIL电子邮件服务。

当第二电子邮件服务(其与第一电子邮件服务断开连接)的用户之一编辑文档并用经编辑的文档作为附件来回复时，第一邮件服务可将改变(其被离线地作出)合并回主文档中。当第一电子邮件服务接收附件并标识文档(以及文档的世系)时，第一电子邮件服务可发起与合并服务的通信。合并服务可就像第一电子邮件服务是编辑器那样来管理合并。

示例场景I：

用户可接收文档以供使用可具有受限计算能力和受限带宽(诸如由于等待时间)的设备(诸如电话)来审阅。当前，如果用户想要在这个环境中在文档上进行评论，即使单个评论或改变也会导致整个文档被传送回服务器。根据一个实施例，访问服务可提供针对用户设备的限制的调节并合并改变被批准的评论复选框(具有是或否)。接着，只有复选框响应的指示可被返回到服务器。通过这种方式，设备从服务获得它需要的数据并能回调服务来更新被批准的评论。服务可取得该指示并执行高保真度修改和/或插入评论。受限设备上的用户相信他/她具有完整的共同创作体验，但是不具有将整个共同创作软件/技术递送到该设备的代价。

示例场景J：

针对消费者设备调节内容的一个示例是其中消费者设备是启用触摸的设备，而文档没有准备好启用触摸。服务可通过例如提供缩放或放大特征来使得文档更加准备好来启用触摸。作为说明性示例，原始在大屏幕设备上创建的、但被提供为在小屏幕设备上渲染的文档中的表格可添加允许表格被放大(以供查看)的触摸方面。

替换地或附加地，通过将小设备的尺寸考虑在内，服务可确定存在只供三列表格中的一列的空间并将以针对小屏幕而言合适的形式来呈现表格。这可包括添加缩放特征或一次仅显示一列。

图8示出了解说在一些实施例中使用的计算设备的各组件的框图。例如，系统800可被用于以能运行一个或多个应用的台式或笔记本计算机或平板计算机或智能电话之类的形式来实现客户端设备、编辑器或阅读器。在某些实施例中，系统800是集成计算设备，诸如集成的PDA和无线电话。应当理解在此描述的系统的各方面适用于移动和传统台式计算机两者以及服务器计算机和其它计算机系统。例如，触摸屏或启用触摸的设备(包括但不限于，启用触摸的轨迹板或鼠标)可对移动和台式设备两者可用。

系统800包括根据一个或多个应用程序810的指令处理数据的处理器805，和/或操作系统820。处理器805连同一个或多个其它组件诸如传感器(例如，磁力计、环境光传感器、邻近度传感器、加速计、陀螺仪、全球定位系统传感器、温度传感器、震动传感器)和网络连接组件(例如，包括无线电/网络接口835)可以是或者被包括在片上系统(SoC)中。

一个或多个应用程序810可被加载到存储器815中并在操作系统820上或与操作系统820相关联地运行。应用程序的示例包括电话拨号程序、电子邮件程序、PIM程序、文字处理程序、电子表格程序、因特网浏览器程序、消息收发程序、游戏程序等等。其他应用可被加载到存储器815中且在设备上运行，包括各种客户端和服务器应用。

可以理解，存储器815可涉及一个或多个存储器组件，包括集成的和可移动的存储器组件，并且一个或多个存储器组件可存储操作系统。根据各个实施例，操作系统包括但不限于来自塞班(Symbian)有限公司的SYMBIAN OS、来自微软公司的WINDOWS MOBILE OS、来自微软公司的WINDOWS PHONE OS、来自微软公司的WINDOWS、来自惠普(Hewlett-Packard)公司的PALM WEBOS、来自运动研究有限公司(Research IN Motion Limited)的BLACKBERRYOS、来自苹果公司的IOS、以及来自谷歌公司的ANDROID OS。构想了其他操作系统。

系统800还包括存储器815内的非易失性存储825。非易失性存储825可被用于存储在系统800断电时不会丢失的持久信息。应用程序810可使用信息并将信息存储在非易失性存储825中，诸如在生产力应用中的内容的创建或修改期间执行的命令记录。同步应用也可被包括并作为应用程序810的一部分驻留，以与在主存机计算机(诸如服务器)上的对应同步应用进行交互，以保持存储在非易失性存储825中的信息与存储在主存计算机上的对应信息相同步。

系统800具有可被实现为一个或多个电池和/或能量收集器(环境辐射、光伏、压电、热电、静电等等)的电源830。电源830还可包括外部功率源，诸如补充电池或对电池重新充电的AC适配器或加电对接托架。

系统800还可包括执行发射和接收无线电频率通信的功能的无线电/网络接口835。无线电/网络接口835通过通信运营商或服务供应商方便了系统800与“外部世界”之间的无线连接。去往无线电/网络接口835的传送在操作系统820的控制下进行，将由无线电/网络接口835接收的通信传播到应用程序810，反之亦然。

无线电/网络接口835允许系统800通过网络与其他计算设备(包括服务器计算设备和其它客户端设备)通信。

音频接口840可被用于向用户提供听觉信号并从用户接收听觉信号。例如，音频接口840可被耦合到扬声器以提供听觉输出，并被耦合到话筒以接收听觉输入，诸如便于电话对话。扬声器也可被合并，使得用户可经由语音命令与计算设备交互。

系统800可进一步包括允许可选相机(未示出)的操作来记录静止图像、视频流等的视频接口845。相机还可被用于捕捉被用于与计算设备交互的姿势。

可经由触摸屏显示器855提供视觉输出。在一些情况中，显示器可能不是触摸屏，且用户输入元素，诸如按钮、键、滚轮等被用来选择作为显示器855上的图形用户界面的一部分来显示的各项。

还可以包括键区860用于用户输入。键区860可以是物理键区或者在触摸屏显示器855上生成的“软”键区。在一些实施例中，显示器和键区是组合的。在一些实施例中，包括音频接口840和视频接口845的两个或更多个输入/输出(I/O)组件可被组合。分立的处理器可被包括有I/O组件，或者处理功能可被内建到处理器805中。

显示器855可呈现图形用户界面(“GUI”)元素、预测性上下文工具栏用户界面、文本、图像、视频、通知、虚拟按钮、虚拟键盘、消息收发数据、因特网内容、设备状态、时间、日期、日历数据、偏好、地图信息、位置信息、以及能够以视觉形式呈现的任何其他信息。在一些实施例中，显示器855是利用任何有源或无源矩阵技术以及任何背光技术(如果使用的话)的液晶显示器件(“LCD”)。在一些实施例中，显示器855是有机发光二极管(“OLED”)显示器。当然，构想了其他显示器类型。

(可与显示器相关联的)触摸屏是被配置成检测触摸的存在和位置的输入设备。触摸屏可以是电阻触摸屏、电容触摸屏、表面声波触摸屏、红外触摸屏、光学成像触摸屏、色散信号触摸屏、声音脉冲识别触摸屏，或者可利用任何其他触摸屏技术。在一些实施例中，触摸屏结合到显示器的顶部作为透明层，以使用户能够使用一个或多个触摸与显示器上所呈现的对象或其他信息交互。

在其他实施例中，触摸垫可结合到不包括显示器的计算设备的表面上。例如，计算设备可具有结合到显示器的顶部的触摸屏以及与显示器相对的表面上的触摸垫。

在一些实施例中，触摸屏是单点触摸触摸屏。在其他实施例中，触摸屏是多点触摸触摸屏。在一些实施例中，触摸屏被配置成检测分立触摸、单点触摸姿势、和/或多点触摸姿势。为了方便起见，这些在此处被统称为手势。现在将描述若干手势。应当理解，这些手势是说明性的，并且不旨在限制所附权利要求书的范围。此外，所描述的手势、附加手势、和/或替换手势可在软件中实现以与触摸屏一起使用。由此，开发者可创建特定应用程序专用的手势。

在一些实施例中，触摸屏支持叩击手势，其中用户在显示器上所呈现的项目上叩击触摸屏一次。出于各种原因，可使用叩击手势，这些原因包括但不限于打开或启动用户叩击的任何事物。在一些实施例中，触摸屏支持双叩击手势，其中用户在显示器上所呈现的项目上叩击触摸屏两次。出于各种原因，可使用双叩击手势，这些原因包括但不限于多级放大或缩小，以及选择文本单词。在一些实施例中，触摸屏支持叩击并保持手势，其中用户叩击触摸屏并维持接触达至少预定义时间。出于各种原因，可使用叩击并保持手势，这些原因包括但不限于打开上下文特定的菜单。

在一些实施例中，触摸屏支持平移手势，其中用户将手指放置在触摸屏上并维持与触摸屏的接触，同时在触摸屏上移动手指。出于各种原因，可使用平移手势，这些原因包括但不限于以受控速率移动通过屏幕、图像、或菜单。还可构想多手指平移手势。在一些实施例中，触摸屏支持轻拂手势，其中用户在用户想要屏幕移动的方向上滑刷手指。出于各种原因，可使用轻拂手势，这些原因包括但不限于水平或垂直滚动通过菜单和页面。在一些实施例中，触摸屏支持捏合和张开手势，其中用户在触摸屏上用两个手指(例如，拇指和食指)进行捏合运动或者将两个手指张开。出于各种原因，可使用捏合和张开手势，这些原因包括但不限于逐步地放大或缩小网站、地图、或图片。

虽然已参考将一个或多个手指用于执行姿势来描述了以上手势，但是诸如脚趾、鼻子、下巴之类的其他附属体以及诸如指示笔之类的物体可用于与触摸屏交互。如此，以上手势应当被理解为说明性的，并且不应被解释为以任何方式进行限制。

应当理解，任何移动或台式计算设备实现系统800可具有比所描述的更多或更少特征，并且不限于在此描述的配置。

例如，在一些实施例中，可在各种类型的用户界面和信息被投射到的墙壁表面上显示和交互各种类型的用户界面和信息。

在各实现中，通过系统800存储的数据/信息可包括本地地存储在设备上的数据高速缓存，或数据可被存储在可由设备通过无线电/网络接口835或通过设备和与设备相关联的一分开的计算设备(例如，分布式计算网络(诸如因特网)中的服务器计算机)之间的有线连接访问的任何数量的存储介质上。如应理解的，此类数据/信息可通过设备经无线电835或经分布式计算网络来被访问。类似地，这些数据/信息可根据已知的数据/信息传送和存储手段来容易地在计算设备之间传送以供存储和使用，这些手段包括电子邮件和协作数据/信息共享系统。

此处所述的特定技术可以在由一台或多台计算设备执行的诸如程序模块之类的计算机可执行指令的一般上下文中描述。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、和数据结构。

各实施例可被实现为计算机进程、计算系统、或者诸如计算机程序产品或计算机可读介质等制品。在此描述的特定方法和过程可被具体化为代码和/或数据，其可被存储在一个或多个计算机可读介质上。本发明的特定实施例构想了以计算机系统的形式的机器的使用，其中一组指令在执行时，可使得系统执行本文所讨论的任意一种或多种方法的指令集。特定计算机程序产品可以是计算机系统可读并且编码指令的计算机程序以执行计算机进程的一个或多个计算机可读存储介质。

计算机可读介质可以是能由计算机系统访问的任意可用的计算机可读存储介质或通信介质。

通信介质包括藉此包含例如计算机可读指令、数据结构、程序模块或其他数据的通信信号被从一个系统传送到另一系统的介质。通信介质可包括有导的传输介质(诸如电缆和线(例如，光纤、同轴等))和能传播能量波的无线(未有导的传输)介质，诸如声音、电磁、RF、微波和红外。计算机可读指令、数据结构、程序模块或其他数据可被体现为例如无线介质(诸如载波或诸如被体现为扩展频谱技术的一部分的类似机制)中的已调制数据信号。术语“已调制数据信号”指的是其一个或多个特征以在信号中编码信息的方式被更改或设定的信号。调制可以是模拟的、数字的或混合调制技术。通信介质(尤其是载波和可包含可被计算机系统使用的数据的其他传播信号)不被包括为计算机可读存储介质。

作为示例而非限制，计算机可读存储介质可包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任意方法和技术中实现的易失性和非易失性、可移动和不可移动介质。例如，计算机可读存储介质包括但不限于，诸如随机存取存储器的易失性存储器(RAM、DRAM、SRAM)；以及非易失性存储器，诸如闪存、各种只读存储器(ROM,PROM,EPROM,EEPROM)、磁性和铁磁/铁电存储器(MRAM,FeRAM)以及磁性和光学存储设备(硬盘、磁带、CD、DVD)；或其它现在已知的介质或今后开发的能够存储供计算机系统使用的计算机可读信息/数据。“计算机可读存储介质”不由载波或传播信号构成。

此外，在此描述的方法和过程可被实现在硬件模块中。例如，硬件模块可包括，但不限于应用专用的集成电路(ASIC芯片)、现场可编程门阵列(FPGA)，和其它现在已知或今后开发的可编程逻辑设备。当硬件模块被激活时，硬件模块执行包括在硬件模块内的方法和过程。

本说明书中对“一个实施例”、“一实施例”、“示例实施例”等的任何引用意味着结合该实施例描述的特定特征、结构或特性被包括在本发明的至少一个实施例中。在说明书中各个地方的这样的短语的出现不必全都指的是同一实施例。此外，在此揭示的任何发明或实施例的任何元素或限制可与任何和/或全部其它元素或限制(单独地或以任何组合)或任何在此揭示的其它发明或实施例进行组合，且全部这样的组合以本发明的范围来构想而没有限制。

应当理解，在此描述的各示例和实施例仅仅是解说目的，鉴于此各种变化或改变可向本领域技术人员建议，并且被包括在这个应用的精神和范围内。

Claims (13)

1.一种方法，包括：

在客户端设备处显示文档中一特征的第一版本；

调用合并服务来请求将对所述文档的修改与主文档合并，所述主文档支持所述特征的第二版本，所述特征的第二版本在所述客户端设备上不被支持，其中调用所述合并服务包括从所述客户端设备向所述合并服务提供修改请求和用于标识所述修改在所述文档内的位置的位置标识符。

2.如权利要求1所述的方法，其特征在于，所述位置标识符包括段落标识符、行标识符、字符标识符和部分标识符中的至少一个。

3.如权利要求2所述的方法，其特征在于，所述修改请求包括用于在所述位置标识符标识的位置处对所述主文档执行一个或多个特定修改的请求，所述一个或多个特定修改诸如突出显示，添加评论，或添加、移除或替换内容；

其中用于执行一个或多个特定修改的请求任选地包括调用对应于所述一个或多个特定修改中的每一个的服务。

4.如权利要求1所述的方法，其特征在于，调用所述合并服务包括提供具有所述修改的所述文档。

5.一种方法，包括：

在客户端设备处，显示文档以供以适合于编辑器的第一格式来编辑；

调用合并服务来请求将对所述文档的修改与主文档合并，所述主文档支持不同于所述第一格式的第二格式，其中调用所述合并服务包括从所述客户端设备向所述合并服务提供修改请求和用于标识所述修改在所述文档内的位置的位置标识符。

6.如权利要求5所述的方法，其特征在于，所述位置标识符包括段落标识符、行标识符、字符标识符或部分标识符；

其中所述修改请求任选地包括用于在所述位置标识符标识的位置处对所述主文档执行一个或多个特定修改的请求，所述一个或多个特定修改诸如突出显示；添加评论；或添加、移除或替换内容。

7.如权利要求5所述的方法，其特征在于，调用所述合并服务包括提供具有所述修改的所述文档。

8.一种其上存储有指令的计算机可读存储介质，所述指令在被计算设备执行时执行包括以下动作的方法：

响应于接收到将对支持特征的第一版本的经编辑的文档的修改与支持所述特征的第二版本的主文档合并的请求，确定对支持所述特征的第一版本的所述经编辑的文档的修改；并且将所述修改合并到支持所述特征的第二版本的所述主文档中，其中将对支持所述特征的所述第一版本的所述经编辑的文档的修改与支持所述特征的所述第二版本的所述主文档合并的请求包括对支持所述特征的所述第二版本的所述主文档的编辑的请求；以及

响应于接收到将对支持第一格式的经编辑的文档的修改与支持不同于所述第一格式的第二格式的主文档合并的请求，确定对支持所述第一格式的所述经编辑的文档的修改；以及将所述修改合并到支持所述第二格式的所述主文档中，其中将对支持所述第一格式的所述经编辑的文档的修改与支持所述第二格式的所述主文档合并的请求包括对针对支持所述第二格式的所述主文档的编辑的单独的修改功能的请求。

9.如权利要求8所述的介质，其特征在于，对合并修改的请求包括具有所述修改的所述文档，其中确定所述修改包括将所述文档的格式或特征版本转换到所述主文档的格式或特征版本并确定经转换的文档和主文档之间的区别。

10.一种方法，包括：

响应于接收到将对支持特征的第一版本的经编辑的文档的修改与支持所述特征的第二版本的主文档合并的请求，确定对支持所述特征的第一版本的所述经编辑的文档的修改；并且将所述修改合并到支持所述特征的第二版本的所述主文档中，其中将对支持所述特征的所述第一版本的所述经编辑的文档的修改与支持所述特征的所述第二版本的所述主文档合并的请求包括对支持所述特征的所述第二版本的所述主文档的编辑的请求；以及

响应于接收到将对支持第一格式的经编辑的文档的修改与支持不同于所述第一格式的第二格式的主文档合并的请求，确定对支持所述第一格式的所述经编辑的文档的修改；以及将所述修改合并到支持所述第二格式的所述主文档中，其中将对支持所述第一格式的所述经编辑的文档的修改与支持所述第二格式的所述主文档合并的请求包括对针对支持所述第二格式的所述主文档的编辑的单独的修改功能的请求。

11.如权利要求10所述的方法，其特征在于，对合并修改的请求包括具有所述修改的所述文档，其中确定所述修改包括将所述文档的格式或特征版本转换到所述主文档的格式或特征版本并确定经转换的文档和主文档之间的区别。

12.一种装置，包括：

用于响应于接收到将对支持特征的第一版本的经编辑的文档的修改与支持所述特征的第二版本的主文档合并的请求，确定对支持所述特征的第一版本的所述经编辑的文档的修改；并且将所述修改合并到支持所述特征的第二版本的所述主文档中的单元，其中将对支持所述特征的所述第一版本的所述经编辑的文档的修改与支持所述特征的所述第二版本的所述主文档合并的请求包括对支持所述特征的所述第二版本的所述主文档的编辑的请求；以及

用于响应于接收到将对支持第一格式的经编辑的文档的修改与支持不同于所述第一格式的第二格式的主文档合并的请求，确定对支持所述第一格式的所述经编辑的文档的修改；以及将所述修改合并到支持所述第二格式的所述主文档中的单元，其中将对支持所述第一格式的所述经编辑的文档的修改与支持所述第二格式的所述主文档合并的请求包括对针对支持所述第二格式的所述主文档的编辑的单独的修改功能的请求。

13.如权利要求12所述的装置，其特征在于，对合并修改的请求包括具有所述修改的所述文档，其中确定所述修改包括将所述文档的格式或特征版本转换到所述主文档的格式或特征版本并确定经转换的文档和主文档之间的区别。