文档处理系统和方法

专利名称：文档处理系统和方法
技术领域：
本发明涉及一种文档处理系统和方法。
背景技术：
信息可大致分为结构化数据和非结构化数据，其中以书面文档和流J 某体为 主的非结构化数据根据资料统计占有量超过百分之七十。结构化数据的结构比 较简单，即一个二维表结构，其处理技术以数据为代表，主要是利用数据库系 统进行处理，从上世纪七八十年代开始发展，到九十年代达到顶峰，研发和应 用已经比较成熟。非结构化数据则没有固定数据结构，因此对非结构化数据的 处理非常的复杂。
目前处理各种非结构化文档的软件已经比较普及，形成了多种文档格式林
立的状况。例如，文档编辑目前就存在Microsoft的word、 WPS、永中的Office、 Red的Office等。通常， 一个内容管理软件往往要处理二三百种文档才各式，而 且这些格式还在不断更新，给这类软件的开发带来了巨大的困难。如何解决文 档通用性、进行数字内容提取、格式兼容越来越成为人们的关注点，人们迫切 希望解决以下问题
1) 文档不通用
基本上，不同用户只能交换同一种软件处理的文档，无法交换不同软件处 理的文档，形成^f言息封闭。
2) 访问接口不统一、数据兼容代价太高
不同的文档处理软件之间，文件格式互不兼容，在处理过程中要么利用对 方组件解析(前提是对方提供相应接口 )，要么自己投入研发力量从头到尾的解 析对方的格式。3) 信息安全较差
目前针对书面文档的权限控制手段单一，主要是数据加密、口令认证。因 为信息泄露，每年造成巨大损失的公司案例层出不穷。
4) 都是针对单个文档的处理，缺乏多文档管理手^:: 每个人电脑中都有大量文档，但多个文档之间缺乏有效的组织管理，而且
资源共享很难。如，字库/字体文件、全文数据;险索等。
5) 页面分层的技术不完善
目前一些软件，如Adobe的photoshop， Microsoft的word，多多少少已经 有层的概念，但层的功能还比较单一，管理手段比较简单，不能满足应用需求。
6) 检索手段不够丰富
随着信息的海量化，用任何一个关键词来搜索都会得到数量庞大的检索结 果，全文检索技术基本解决了查全率的问题，但查准率迅速上升为首要问题。 现有技术还没有很充分地利用全部信息来解决查准率问题，例如每个文字的字 体、字号完全可以用来判断该文字的重要性，但都在^r索时被忽略了。
虽然各大公司目前都努力将自己特有的文档格式发展为市场标准，各标准 组织也致力于制订通用的文档格式标准。但不管是专有的文档格式(如.doc) 还是开放的文档格式(如PDF)，只要是以文档格式为标准，就不可避免产生以 下问题
a) 重复开发，效果不统一
使用同一标准的不同软件都需要自己去解释、生成该格式的文档，造成大 量重复开发，而且会因为各家解释程序不同，例如有的完善有的相对简单，有 的支持新版本有的只支持旧版本数据，同 一文档在不同软件下显现出不同的版 式，甚至出现解释错误导致无法打开文档。
b) 阻碍创新
软件是不断创新的行业，但由于每增加一个新功能就需要增加描述该功能 的信息，而且只有等到标准修订的时候才能增加新的格式，因此把存储格式固 定死，将会妨碍技术创新的竟争。C)影响检索性能
对海量信息，需要增加大量的检索信息以提高检索性能，但固定死的存储 格式难以增加检索信息
d)影响可移植性和可伸缩性
在不同的系统环境下，不同的应用需求，可能会有不同的存储要求。例如， 存储在硬盘上就需要考虑如何减少磁头寻道的次数以提高性能，而在嵌入式应 用中数据都相当于存储在内存中的，就不存在这个问题。例如，同一个厂商的 数据库软件在不同平台上就可能会使用不同的存储格式。因此，设置文档存储 标准将会影响系统的可移植性和可伸缩性。
现有技术中最开放、可交换性最好的文档是Adobe Acrobat的PDF。然而， 虽然PDF已经成为全球文档分发、交换的事实标准，但也不能实现在不同的软 件之间交换PDF文档，也就是说，不能实现PDF文档的互操作性。而且，无 论是Acrobat还是O伍ce，都只能对单文档进行处理，缺乏对多文档的管理功能， 不具备对文档库进行操作的功能。
另外，在文档信息安全的方面，现有技术也存在较多缺陷。Word和PDF 这些应用最广泛的文档，都是釆用对数据加密或者口令认证等进行数据安全控 制，没有提供系统的身份认证机制，对权限的控制都是整个文档范围的，不能 细化到文档内的任意区域，无法对任意逻辑数据设定加密和签名。现有的内容 管理系统虽然能够提供较好的身份认证机制，但由于与文档处理系统是分离的， 不仅管理粒度只能做到文档级，而且无法在文档使用过程中对文档实施安全控 制，难以进行必要的安全管理。由此可见，由于现有的安全机制与文档处理是 分离的模块，容易出现安全缝隙。

发明内容
本发明实施例提供了 一种文档处理的系统和方法，实现对文档的互操作。
本发明实施例提供的文档处理方法，包括
应用软件发送指令到平台软件，以对抽象非结构化信息进行操作；平台软件接收到来自所述应用软件的指令，根据所述指令，对与所述抽象
非结构化信息对应的存储数据执行所述操作；
其中，所述抽象非结构化信息与所述存储it据的存储方式无关。
本发明实施例提供的一种文档处理系统，包括
应用软件，用于发送指令到平台软件，以对抽象非结构化信息进行揭:作； 平台软件，用于接收到来自所述应用软件的指令，根据所述指令，对与所 述抽象非结构化信息对应的存储数据执行所述操作；
其中，所述抽象非结构化信息与所述存储数据的存储方式无关。
本发明实施例提供的一种文档处理方法，包括
第 一应用软件发送第 一指令到平台软件，以创建第 一抽象文档；
所述平台软件接收所述第一指令，创建与所述第一抽象文档对应的存储数
据；
第二应用软件发送第二指令到所述平台软件以打开所述创建的存储数据； 所述平台软件接收所述第二指令，打开并解析所述存储数据，生成与所述
存储数据对应的第二抽象文档；
其中，所述第一指令与第二指令符合相同的接口标准。 本发明实施例提供的一种文档处理系统，包括 第一应用软件，用于发送第一指令到平台软件，以创建第一抽象文档； 所述平台软件，用于接收所述第一指令，创建与所述第一抽象文档对应的
存储数据；
第二应用软件，用于发送第二指令到平台软件以打开所述创建的存储数据； 所述平台软件，进一步用于接收所述第二指令，打开并解析所述存储数据， 生成与所述存储数据对应的第二抽象文档；
其中，所述第一指令与第二指令符合相同的接口标准。 本发明实施例提供的一种文档处理方法，包括
第 一平台软件解析以第 一数据格式存储的第 一存储数据，生成与所述存储 数据对应的第 一抽象文档；所述应用软件发送第 一指令到所述第 一平台软件，以获取所述第 一抽象文 档的所有信息；发送第二指令到第二平台软件，以创建与所述第一抽象文件相
同或相似的第二抽象文档；
所述第二平台软件根据所述第二指令，创建与所述第二抽象文档对应并按 第二数据格式存储的第二存储数据；
其中，所述第一指令和第二指令符合相同的接口标准。
本发明实施例提供的一种文档处理系统，包括
第一平台软件，用于解析以第一数据格式存储的第一存储数据，生成与所 述存储数据对应的第 一抽象文档；
所述应用软件，用于发送第一指令到所述第一平台软件，以获取所述第一 抽象文档的所有信息；发送第二指令到第二平台软件，以创建与所述第一抽象 文件相同或相似的第二抽象文档；
所述第二平台软件，用于才艮据所述第二指令，创建与所述第二抽象文档对 应并按第二数据格式存储的第二存储数据；
其中，所述第一指令和第二指令符合相同的接口标准。
利用本发明实施例提供的方法和系统，应用软件对一个抽象文档执行操作， 因此它无需考虑文档的数据是如何存储的。平台软件维护抽象文档和存储数据 (如具有某种格式的文档文件)之间的关系，如平台软件将应用软件针对抽象 问的那个的操作映射到对存储数据的实际操作，并对存储数据执行此操作。这 样应用软件和平台软件实现了分工，进而实现文档的互操作。


图1为依照本发明的文档处理系统的结构框图。 图2示出了依照本发明优选实施例的通用文档模型的组织结构。 图3示出了图2所示通用文档^^莫型中文档库对象的组织结构。 图4示出了图3所示文档库对象中文档库辅助对象的组织结构。 图5示出了图3所示文档库对象中文档集对象的组织结构。图6示出了图5所示文档集对象中文档对象的组织结构。 图7示出了图6所示文档对象中页面对象的组织结构。 图8示出了图7所示页面对象中层对象的组织结构。 图9示出了图8所示层对象中版面对象的组织结构。 图10-17为本发明的实施例中所定义的动作。 图18为以UOML接口为例的文档处理系统的处理示意图。
具体实施例方式
以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处 所描述的具体实施例仅仅用于解释本发明，并不用于限定本发明。
如图l所示，依照本发明的文档处理系统主要包括应用软件、接口层、文 档库系统和存储设备。
其中的应用软件包括现有的任何文档处理和内容管理软件，这些应用软件 都位于文档处理系统的应用层，通过发送符合接口标准的指令来对文档进行操 作，所述操作都是对符合通用文档模型的文档进行的，与具体存储格式无关。
其中的接口层符合规范应用层和文档库系统之间交互的接口标准，所述应 用层通过接口层向文档库系统发送标准指令，所述文档库系统通过接口层向应 用层返回执行的结果。由此可见，由于应用软件均可以通过接口层发出标准指 令，对符合通用文档模型的文档进行操作，所以不同的应用软件可以通过同一 文档库系统对同 一文档进4亍#:作，同 一应用库欠件也可以通过不同文档库系统对 不同格式的文档进行操作。
优选地，接口层可包括上接口单元和下接口单元，应用层通过上接口单元 发送标准指令至下接口单元，文档库系统通过下接口单元接收标准指令，下接 口单元还用于将文档库系统的执行结果通过上接口单元返回给应用系统。在实 现上，上接口单元可位于应用层中，下接口单元可位于文档库系统中。
其中的文档库系统为文档处理系统的核心层，根据应用软件通过接口层发
来的标准指令执行具体的文档处理操作。
其中的存储设备为文档处理系统的存储层，常用的是硬盘或者内存，也可以是光盘、闪存、软盘、磁带，也可以是远程的存储设备，总之只要具备数据 的存储能力即可。在存储设备中存储有多个文档，但对应用软件而言并不需要 关心文档的具体存储方式。
由此可见，依照本发明，使得应用层和数据处理层真正分离开来，文档不 再与特定应用软件绑定，应用软件不再直接跟具体的文档格式打交道，不同的 应用软件可以对符合通用文档模型的同 一文档进行编辑，使不同应用软件之间 具有良好的文档互操作性。
本发明还公开了一种应用软件，其包括用于发出标准指令的接口单元，所 述标准指令用于对符合通用文档才莫型的文档进行操作。
本发明还公开了一种文档库系统，其包括用于接收标准指令的接口单元； 和，用于根据该标准指令对符合通用文档模型的文档进行操作的处理单元。 本发明还公开了一种接口层，其包括
上接口单元，用于发送对符合通用文档模型的文档进行操作的标准指令； 下接口单元，用于接收该标准指令。
进一步，上接口单元可以才艮据应用层发出的指令生成标准指令，下接口单 元判断接收到的指令是否符合标准，并解析符合标准的指令。
文档处理系统可以包括应用软件和平台软件(如文档库系统)。应用软件通 过发送一个或多个指令到平台软件来对抽象非结构化信息(abstract unstructured information)进行操作。平台软件接收到来自应用软件的指令后，将针对抽象 非结构化信息的操作映射到针对与该非结构化信息对应的存储数据的4喿作，并 且对该存储数据执行该操作。其中，需要说明的是抽象非结构化信息与存储 数据的存储方式无关。
存储数据是指维护或存储在存储器(诸如硬盘等非易失性永久存储器，或 诸如RAM等易失性存储器)中供长期使用的各种信息，这些信息可由计算装 置处理。存储数据可以包括一份完整的或综合的信息，如o伍ce文档、图片或 音频/视频节目等。这里"长期"不是指存储的介质，而是指数据的形式，表明 数据不是动态存储(例如运行实例中的一个内存指针)的，而是可被其他软件或另 一个运行实例以后^f吏用的。
存储数据通常包含于一个磁盘文件中，但也可以包含在多个(相关联的) 磁盘文件中或在数据库的多个(相关联的)字段中，或者是在一个独立的磁盘 分区的一个区域中。其中，该磁盘分区不由操作系统的文件系统管理，而是由 平台软件直接管理。可选的，存储数据还可以分布式存储在不同地理位置的不 同设备上，也可以具有其他存储形式。由此可见，存储数据的格式可以包括如 上所述的将信息存储为物理数据的各种形式，而不局限于一个或多个;兹盘文件 的格式。
文档的存储数据可称为文档数据，除了包含文档的可视化信息以外，还可 以包含其它一些信息，例如安全控制信息或编辑过程信息。文档文件是以磁盘 文件方式存储的文档l史据。
这里"文档，，通常有两个含义 一个是指可打印到纸上的信息，如静态的 二维信息(static two-dimension information);另 一个则泛指所有可呈现的信息， 包括多维信息或诸如音/视频等的流媒体信息。本发明中并不严格区分这两种用 法。
在本发明实施例中，应用软件仿佛是对一个抽象文档进行操作，它并不需 要关心文档数据的存储方式。平台软件(如文档库系统)负责维护抽象文档与 存储数据(如具有特定格式的文档文件)之间的对应关系，比如将应用软件 对抽象文档执行的操作映射到针对存储数据的实际操作，执行此操作，并在操 作需要返回值的情况下，向应用软件返回操作结果。
在本发明实施例中，抽象文档是对文档数据进行抽象的结果，不同的文档 数据可以对应相同的抽象文档。例如，抽象文档可以基于文档的可视化外观(也 称为文档的版式)进行抽象，具有相同可视化外观的不同文档数据，无论其以 何种方式存卡者，都可以对应同一抽象文档。比如，当一个Word文件;故转成一 个与其具有相同可一见化外)i见的PDF文件后，该Word文件与该PDF文件就是对 应同一抽象文档的不同存储数据。又比如当同一文档被保存为不同版本的Word 格式文件时，这些不同版本的Word格式文件也是对应相同抽象文档的不同存储数据。
在本发明实施例中，为了更好地记录可视化外观信息，最好能记录文字、 图形、图像等可视内容的位置信息，并同时记录所引用的资源，例如^皮链接的 照片和非标准字库。这样，就能保证这些可视内容不会错位、并且随时可用。 版式文档满足上述条件，因此常常被用作平台软件的存储数据。
由于平台软件创建的存储数据可被标准指令访问，并且可被符合接口标准 的各种应用软件使用，因此平台软件创建的存储数据又可称为通用数据。应用
软件不仅可以访问通用数据，还可以定义自己特有的数据格式，如O伍ce文档
格式。应用软件打开并解析具有自己特有格式的文档后，通过一个或多个标准 指令来请求生成相应的抽象文档，平台软件再根据这些指令创建相应的存储数 据。虽然新生成的存储数据(通用数据)与原始数据的格式不同，但其与原始 数据对应相同的抽象文档，如其具有与原始数据相同或者相似的可视化外观。 因此，只要一个文档数据(无论其格式如何)对应一个抽象文档，平台软件就 可以创建一个与该抽象文档对应的存储数据，任何文档数据都可以被转化为与 其对应相同抽象文档的通用文档，并可纟皮各种应用软件使用。这样就实现了在 符合相同接口标准的不同应用软件之间的文档互操作。
下面以两个应用软件和一个平台软件为例(但不限于此)来说明文档互操 作过程。第一应用软件发送第一指令到平台软件，以创建第一抽象文档。平台 软件接收到第一指令后，创建与第一抽象文档对应的存储数据。第二应用软件 发送第二指令到平台软件以打开上述已创建的存储数据。平台软件根据第二指 令打开并解析该存储数据，并产生与该存储数据对应的第二抽象文档。这里第 二抽象文档与第 一抽象文档相同或相似，并且第 一指令和第二指令符合相同的 接口标准，这样第二应用软件就可以打开由第 一应用软件创建的文档。
再以一个应用软件和两个平台软件为例(但不限于此)来说明另一文档互 操作过程。第一平台软件解析以第一数据格式存储的第一存储数据，产生与该 存储数据对应的第一抽象文档。应用软件发送第一指令到第一平台软件，以获 取第一抽象文档的所有信息。应用软件发送第二指令到第二平台软件，以创建一个与第 一抽象文件相同或相似的第二抽象文档。第二平台软件根据第二指令， 创建与第二抽象文档对应的并且按第二数据格式存储的第二存储数据。这里第 一指令和第二指令符合相同的接口标准这样应用软件可以将数据在不同格式间 转化并且保持其抽象特征不变。
多个应用软件与多个平台软件情况下的文档互操作过程可由以上两个例子 推知。
受到文档格式和相关软件功能等因素的限制，存储数据与抽象文档的映射 关系不一定能100%完整准确，往往会存在一定程度上的偏差。例如(但不限于 此)，不管用什么精度的浮点数还是整型数来存储可视内容的坐标，都不能避免 出现偏差。又如，缺乏必要色彩管理功能的用于显示/打印的软件显示/打印出来 的颜色和预定义的颜色可能会有一定偏差。如果这些偏差不是很明显的话(例
如但不限于此，某个字符的位置偏离了 O.Olmm,或者某个图像用JPEG进行了 失真压缩)，这些偏差可以被使用者忽略。使用者所能接受的偏差程度与其实际 需求等因素有关，例如一个专业美工对色彩偏差的要求就会比一般人苛刻得多。 由此可见，抽象文档与相对应的存储凄t据不一定能绝对一致，与一个抽象可视 化外观对应的多个存储数据，其显示/打印效果也未必绝对相同。即使用相同的 应用软件来处理同样的存储数据，其呈现效果也不一定会完全一样，例如不同 的屏幕分辨率下显示效果就会有细^t的不同。在本发明中，"相似"、"一致"被 用来表示可接受的范围内的偏差(即偏差程度不超过预设的阈值)。由此可见， 存储数据可以与多个相似的抽象文档相对应或相符合。
平台软件可以用多种方式建立抽象文档与存储数据的对应关系。例如，平 台软件可以在打开某个文档文件、解析该文档文件的存储数据并形成一个可供 应用软件操作的抽象文档时，建立此抽象文档和存储数据的对应关系。又如， 平台软件可以在接收到来自应用软件指令以指示创建一个抽象文档、并创建相 应的存储数据时，建立此抽象文档和存储数据之间的对应关系。在本发明某些 实施例中，应用软件知道其所操作的抽象文档所对应的存储数据(比如此时 应用软件可以通知平台软件该存储数据的地址，或者应用软件可以将文档数据读到内存中，并将内存数据块提交给平台软件供其处理)。在本发明另外的实施 例中，应用软件可能对其所操作的抽象文档所对应的存储数据"一无所知"。例 如(但不限于此)，应用软件可以要求平台软件在互联网上按某个条件搜索，并 打开第一个搜索到的文档。
一般说来，抽象文档是不具有存储的，也就是说其并未存储在任何存储介 质中。各种用于记录和描述抽象文档的信息可以包含在对应的存储数据或操作 指令中，但这种信息都不是抽象文档本身。因此，抽象文档也可被称为虚拟文 档。
在本发明实施例中，抽象文档可以具有结构，该结构可以用某种文档模型 来描述，如以下提到的通用文档模型。所谓"文档数据符合通用文档模型"可 以理解为对文档数据进行抽象得到的抽象文档符合通用文档模型。由于通用文 档模型是基于纸张特性抽象而来，因此所有可打印到纸上的文档符合通用文档
模型，这就是通用文档模型之所以称为"通用"的由来。
在本发明实施例中，除了可视化外观外，还可以从文档数据中抽取其他各 种信息，如安全控制信息、文档组织管理信息(例如描述一个文档属于哪个文 档集的信息)、导航导读等互动信息、元数据等非可视信息等各种信息进行抽象， 甚至还可以是多维信息以及如音/视频信息等的流媒体信息。所有这些被抽取的 信息可以统称为抽象信息。由于抽象信息本身是没有存储的，也可以称为虚拟"息。
虽然本发明所举的实施例大都是针对文档的可视化外观信息的，但上述方 法也可用于其他的抽象信息，如安全控制信息、文档组织管理信息、多维信息、 流媒体信息等。
存在多种方式来发送指令以操作抽象信息，如通过发送命令串或调用函数。 可以用不同的指令形式来表示对抽象信息进行的操作。之所以将函数调用也视 为一种指令发送形式，是因为可以将不同函数调用地址视为不同指令，将函数 的参数视为对应的指令参数。当指令以"操作动作+操作对象，，形式描述时，
指令中的对象可以与通用文档模型中的对象相同，也可以不同。例如，设置文档的文字对象的位置时，指令中的对象可以是文字对象，此时此指令中的对象
与通用文档模型中的对象相同；或者，指令中的对象可以是文字的位置对象， 此时此指令中的对象与通用文档模型的对象不同。在实际应用中，为了方便起 见，还是应当尽量将指令中的对象可以与通用文档模型的对象统一为好。
以上描述的方法将应用软件从平台软件中分离处理，使得文档处理更加便 利。在实际应用中，也可能会出现不严格区分抽象信息与存储数据，应用软件 甚至可以通过指令直接操作文档数据的情形。但在这种情况下，为了保持通用 性，指令应该与具体的文档数据格式无关。更具体的，该指令可以符合一个与 文档数据格式无关的接口标准，并可以通过这个符合该接口标准的接口层发送 该指令。接口层也可以不是一个单独的层，而是可以分为上接口单元和下接口 单元两部分，其中上接口单元为应用软件的一部分，下接口单元为平台软件的 一部分。
以下对本发明的文档处理系统的具体实施方式
进行阐述。 通用文档模型
可参考纸张的特性定义所述通用文档模型，这是因为以纸张作为文档信息 的记录手段是通行至今的标准方法，只要能具备纸张的所有功能，就能满足工 作、生活等实际应用的需求。
如果把文档中的一页当成一张纸，凡是能画到纸上的就记录下来，该通用 文档模型能够描述页面上的所有可见内容。现有技术中的页面描述语言(如 PostScript)可以描述所有能印在纸上的信息，因此这一部分就不再详细阐述。 一般说来，页面上的可见内容最终都可以归为文字、图形、图像三类。
如果文档中涉及到特定字体或特殊字符的话，为了保证在各台电脑上都能 有相同的效果，就需要在文档中嵌入相应字库。为了提高存储效率，字库资源 应当共享，这样即使在多处使用了同一字符，也只需要嵌入一个字库。图像有 时也是可能在多处出现的，例如每一页共同的底图，或经常出现的公司标识， 这种情况下最好也能共享这些图像。
当然，作为更加先进的信息处理工具，不能仅仅模拟纸张的特性，还需要增加一些增强的数字特性，例如元数据、导航、导读、微缩版面。元数据是描 述数据的数据，例如作者、出版社、出版时间、ISBN号等就是图书的元数据。 元数据是业内通用名词，也不在此赘述。导航是类似图书目录的信息，也是业 内通用名词。导读信息描述了一篇文章所在的区域和阅读顺序，这样当阅读者 读完一屏后就可以根据该信息自动判断下一屏应该显示什么，这样还能做到自 动换栏、自动转版，而不用阅读者再手工指定位置。微缩版面是事先生成的各 页面的微缩图，阅读者可以通过查看微缩版面来指定阅读哪一页。
图2是本发明的一优选实施例的通用文档模型。如图2所示，该通用文档
模型包含文档仓库、文档库、文档集、文档、页、层、对象组、版面对象等多 个层次。
其中，文档仓库由一个或多个文档库组成，文档库之间的关系相对于文档 库之下的层次之间的关系相对要松散一些，文档库之间可以非常简单地组合和 拆离，而不用对文档库本身的数据做改动，该多个文档库之间往往没有建立统 一索引(特别是全文索引)，很多对文档仓库的检索操作一般都需要遍历各文 档库的索引，而没有统一的索引可用。每个文档库由一个或多个文档集组成， 每个文档集由一个或多个文档组成，还可以包含任意数量的子文档集。这里所
说的文档相当于目前普通的一个文档文件(例如DOC文档)，通用文档才莫型 可以规定一个文档只能属于一个文档集，但也可以允许一个文档属于多个文档 集。文档库不是多个文档的简单组合，它把多个文档紧密地组织起来，特别是 为文档内容统一建立了各种检索索引后就能带来更大的便利性。
每个文档由一页或存在一定顺序(如前后顺序)的多页组成，每页的版心 可以不同，而且版心也不一定是矩形的，可以是任意形状，可以用一条或多条 封闭曲线表示版心。
每页又由一层或按一定顺序(如上下顺序)的多层组成，各层之间如同玻 璃板的叠加关系。层由任意数量的版面对象和对象组组成，版面对象是指状态 (如字体、字号、颜色、ROP等)、文字(包括符号)、图形(如直线、曲线、 填充了指定颜色的闭合区域、渐变色等)、图象(如TIF、 JPEG、 BMP、 JBIG等)、语义信息(如标题开始、标题结束、换行等)、源文件、脚本、插件、 嵌入式对象、书签、链接、流媒体、二进制数据流等。 一个或多个版面对象可 以组成一个对象组。对象组也可以包含任意数量的子对象组。
文档库、文档集、文档、页、层都可以还包括元数据(如名称、最后修改 时间等，其类型可以根据应用需求来设置)和/或历史痕迹；文档中还可以包
括导航信息、导读信息、微缩版面；也可以把微缩版面放在页或者层这个层次； 文档库、文档集、文档、页、层、对象组都可以还包括数字签名；语义信息最 好跟着版面信息走，这样可以避免数据冗余，也比较容易与版面建立对应关系； 文档库、文档还可以包括字库、图像等共享资源。
该通用文档模型还可以定义一个或多个角色，为每个角色分配一定权限。 权限以文档库、文档集、文档、页、层、对象组、元数据为单元进行分配，定 义每个角色对该单元是否可读、是否可写、是否可复制、是否可打印，等等。
该通用文档模型是一个超越以往单个文档对应单个文件的方式，文档库中 包含多个文档集、文档集中包含多个文档，而对于文档库中文档内容，采用了 细粒度的访问和安全控制，可以具体访问文档库中某个文字或者矩形，而不像 现在的文档管理系统只能访问到文件名。
图3至图9示出了本发明一优选实施例的通用文档模型所涉及的各对象的 组织结构示意图。所述的各对象的组织结构是树状结构，是逐层展开、细化的。
文档仓库对象是由一个或多个文档库对象组成(图中未示出)。
如图3所示，文档库对象包括一个或多个文档集对象、任意数量文档库辅 助对象和任意数量的文档库共享对象。
如图4所示，所述的文档库辅助对象包括元数据对象、角色对象、权限对 象、插件对象、索引信息对象、脚本对象、数字签名对象、历史痕迹对象等。 文档库共享对象是指文档库中的不同文档可能共享的对象，如字库对象、图像 对象等。
如图5所示，每个文档集对象包括一个或多个文档对象、任意数量的文档 集对象和任意数量的文档集辅助对象。文档集辅助对象包括元数据对象、数字签名对象、历史痕迹对象。当文档集对象包括多个文档集对象时，其类似于资 源管理器中的文件夹包括多个文件夹的形式。
如图6所示，每个文档对象包括一个或多个页面对象、任意数量的文档辅 助对象和任意数量的文档共享对象。文档辅助对象包括元数据对象、字库对象、 导航信息对象、导读信息对象、微缩版面对象、数字签名对象、历史痕迹对象 等。文档共享对象包括文档中的不同页面可能共同使用的对象，如图^象对象、 印章对象等。
如图7所示，每个页面对象包含一个或多个层对象和任意数量的页面辅助 对象组成。页面辅助对象包括元数据对象、数字签名对象、历史痕迹对象。
如图8所示，每个层对象包括一个或多个版面对象、任意数量的对象组和 任意数量的层辅助对象。层辅助对象包括元数据对象、数字签名对象、历史痕 迹对象。对象组包括任意数量的版面对象、任意数量的对象组和可选的数字签 名对象。当对象组包括多个对象组时，其类似于资源管理器的文件夹包括多个 文件夹的形式。
如图9所示，版面对象包括状态对象、文字对象、直线对象、曲线对象、 圆弧对象、路径对象、渐变色对象、图像对象、流媒体对象、元数据对象、批 注对象、语义信息对象、源文件对象、脚本对象、插件对象、二进制^:据流对 象、书签对象以及超链接对象。
其中，状态对象包括任意数量的字符集对象、字体对象、字号对象、文字 颜色对象，光栅操作对象、背景色对象、线颜色对象、填充色对象、线型对象、 线宽对象、线接头对象、画刷对象、阴影对象、阴影颜色对象、旋转对象、空 心字对象、勾边字对象、透明对象和渲染模式对象。
在具体实施过程中，可以在上述通用文档^^莫型基础上进一步增强或简化。 如果在简化模型中省略了文档集对象，则文档库对象直接由文档对象组成；如 果在简化模型中省略了层对象，则页面对象直接由版面对象组成。
可以理解，最简化的通用文档模型是仅包含文档对象、页面对象和版面对 象。其中版面对象仅包括文字对象、直线对象和图像对象。完整模型和最简化模型之间的各种中间模型都属于本优选实施例的变形。
通用安全模型
为了满足各种应用对文档安全性的需求，还需要定义一种通用的文档安全 ^t型，以解决由于现有软件的文档安全功能不够强，或者是安全管理^4'J与文 档处理模块脱节所导致的安全缝隙。根据本发明一优选实施例，通用文档安全 模型包括
1. 在文档库中设置若干角色，角色对象是文档库对象的子对象。
2. 可以设置任意角色对任意对象(例如文档库、文档集、文档、页、层、 对象组、版面对象等)的访问权限。如果设置了某角色对某对象的访问权限， 则该^L限适用于该对象的所有子对象。
3. 文档库系统实现的访问权限包括是否可读、是否可写、是否可再授权、 是否可收回授权及其排列组合。也可以定义其他需要由应用软件来配合实现的 ^J艮，如不可打印。
4. 角色可以对任意对象进行签名。签名范围包括该对象的子对象，以及 引用到的对象。
5. 创建角色对象的指令的执行结果是向应用软件返回一个密钥，作为应 用软件以该角色身份登录的依据，该密钥通常是PKI的私钥，由应用软件保管， 该密钥也可以是登录口令。
6. 当应用软件以某一角色身份登录时，通常采用"挑战-应答"机制，即 文档库系统用保存的角色公钥加密一块随机数据发给应用软件，应用软件解密 后返回给文档库系统，如果解密正确，则表明应用软件确实拥有该角色对应的 私钥。"挑战-应答"机制也可以用以下方式实现，文档库系统将一块随机数据 发给应用软件，应用软件用私钥加密后返回给文档库系统，文档库系统用保存 的角色的公钥解密，如果解密正确，则表明应用软件确实拥有该角色对应的私 钥。为保险起见，该认证过程可能会重复几次。采用"挑战-应答"机制可以更 好地保护私钥的安全性。如果角色的密钥是登录口令，则需要用户输入正确的 登录口令。7.应用软件可以同时登录多个角色，此时拥有的权限是各角色权限的并集。
在具体实施过程中，可以在上述通用安全模型基础上进一步增强或筒化。 针对上述安全模型的任何简化模型都是本实施例的变形。 接口层的具体实现
所述接口层的统一接口标准可根据通用文档模型、通用安全模型和常用的 文档操作而定义，用于发送对通用文档模型中各对象进行操作的指令。所述的 对通用文档模型中各对象进行操作的指令符合接口标准，各种应用软件可以通 过接口层发出标准指令。
现在介绍接口标准的实现方式。接口标准的实现可以是上接口单元按照预
先定义的标准才各式生成命令串，例如"<UOML_INSERT (OBJ=PAGE, PARENT=123.456.789, POS=3)/>，，，将该命令串发送给下接口单元，并从下接 口单元接收文档库系统对该命令的执行结果或其它反馈信息；或者，接口标准 的实现是下接口单元提供一些具有标准名称和参数的接口函数，例如"BOOL UOI—InsertPage (UOI—Doc *pDoc, int nPage)，，，上接口单元调用这些标准函数， 调用操作本身就代表上接口单元发出了标准指令；或者是上述方法的组合。
接口标准釆用"操作动作+操作对象"的方式来实现便于学习和理解，也便于 保持接口标准的稳定性。例如，对20种不同对象进行10种操作，可以定义 20x10=200种指令，也可以定义20种对象和10种动作，但显然后一种方式大 大减轻了记忆的负担，而且今后在对接口标准进行扩充时，增加一个对象或动 作也很简单。所述操作对象为通用文档模型所包含的对象。
例如，定义以下7种操作动作
打开用于创建或打开文档库；
关闭用于关闭会话句柄、关闭文档库；
获取用于获取对象列表、对象相关属性和数据；
设置用于设置/修改对象数据；
插入插入指定对象或数据；删除用于删除对象的某个子对象；
检索查询用于根据定义条件在文档中找到符合条件的内容，这些条件既 可以是准确的信息，也可以是不准确的信息，即模糊查找。
定义如下对象文档库、文档集、文档、页、层、对象组、文字、图像、 图形、路径(由一组顺序图形连接组成，可以是闭合也可以不闭合的)、源文 件、脚本、插件、音频、视频、角色等。
对象还包括下列状态对象背景色、线的颜色、填充色、线型、线宽、ROP、 画刷、阴影、阴影颜色、字符高、字符宽、旋转、透明、渲染模式等。
可以理解，在采用"操作动作+操作对象"方式实现接口标准时，不能自动理 解为每一个对象和每一个动作的所有组合都一定能构成有实际意义的操作指 令， 一些组合是没有意义的。
还可以用非"操作动作+操作对象"的函数方式来定义接口标准，例如对每 一个对象的每一种操作都定义一个接口函数，这样各种操作指令就是上接口单 元以调用下接口单元的接口函数来发送给文档库系统。
还可以封装各个对象类，如文档库类，把该对象可以进行的操作定义成该 类的方法。
特别地，如果在接口标准中定义了获取版面位图的指令，将对保障版面一 致性和文档互操作性起到非常关键的作用。
在检索查询指令中，除了常规的关键词检索外，还可以提供更加丰富的检 索手段。在常规的搜索技术中，搜索是和文档处理分离的，搜索程序只能从文 档中提取纯文本信息，而无法获取更多信息，只能基于文本信息检索。但在本 发明中，检索查询功能是集成在文档处理的核心层，即文档库系统，这样就可 以更充分地利用文档中蕴含的信息来提供更为强大的4全索手段，如
1. 基于字体信息的检索，如检索黑体字的"书生"，Times New Roman字体 的"S薦n"
2. 基于字号信息的检索，如检索三号字的"书生"，20磅以上的"Sursen", 长字(即字高超过字宽)的"文档库，，3. 基于颜色的才全索，如才全索红色的"书生"，蓝色的"Sursen"
4. 基于版面位置的检索，如检索位于页面上半部分的"书生"，位于页脚的 "Su羅，，
5. 基于特殊修饰效果的检索，如检索斜体字的"书生"，顺时针旋转30度 至90度之间的"Sursen",空心字的"SEP",勾边字的"文档库"
6. 根据类似的思路，还可以进一步提供其它类型的检索，如检索反白(黑 底白字)的"书生"，压图的"Sursen，，等
7. 可以检索多个版面对象的组合，如"书生"距离"Sursen"不超过5厘米
8. 上述检索条件的任意组合
以下是用"操作动作+操作对象"的方式实现接口标准的 一 个实施例，在该 实施例中，接口称为非结构操作标记语言(UOML),是用可扩展标记语言 (XML)描述的一系列的命令。每个动作都对应一个XML元素，每个对象 也都对应一个XML元素；描述一个命令时，将描述对象的XML元素作为 描述动作的XML元素的子元素，即可生成包括动作+对象的字符串。上接 口单元将该字符串发送给下接口单元，就将相应的操作指令发送给了文档库 系统。文档库系统执行这些命令后，下接口单元将执行结果也生成一个符合 UOML格式的字符串，返回给上接口单元，使应用软件能够知晓操作执行结 果。
所有执行结果都由UOML—RET表示，参见图10,其定义如下 属性
SUCCESS:值为真(true)时表明操作成功，否则失败。 子元素
ERR_INFO:可选，仅当操作失败时出现，描述了相应的错误信息。 其它子元素根据具体命令确定，可参考各命令说明。 UOML动作包括
1 UOML—OPEN创建或打开文档库，参见图11。 1.1属性1.1.1 create:为true时是创建，否则是打开已有文档库。 1.2子元素
1.2.1 path:文档库路径。可以是磁盘文件名，也可以是URL,或者是内存 指针，或者是网络路径，或者是文档库的逻辑名称，或者其它能够指定文档库 的表示方法。可以用不同特征的字符串区分上述各种情况，即不用改变命令格 式，只要给字符串设置不同特征，就可以用不同的方法指定文档库。例如，磁 盘文件名采用设备名称(如盘符)和":"开头(如"C:"、 "D:"),而且紧跟着":" 不会是"〃"，也不会是又一个":"；URL采用协议名称和":〃"开头(如"http:〃")； 内存指针用"MEM::"开头，后面是指针的字符串表示方式，例如 "MEM::1234:5678，，；网络路径是"W，，开头，后面是服务器名，以及服务器上的路 径，如"\\server\abc\def.sep"; 文档库的逻辑名称可以用"*，，开头，如 "*MyDocBasel"。在下接口单元解析时，如果第一个字母是"*"就表明该字符串 代表文档库的逻辑名称；否则如果头两个字母是"W"就表明该字符串代表网络路 径；否则如果头五个字母是"MEM::"就表明该字符串代表内存指针；否则寻找 字符串的第一个":"，如果该":，，后面是"〃"该就表明字符串代表URL,否则就代 表本地设备上的文件。对于打开服务器上的文档库的情形，可以设立一个专门 的URL协议来区分，例如用"Docbase:〃myserver/mydoc2"指明打开服务器 myserver上运行的文档库系统服务器系统所管理的mydoc2文档库。 总之，只要能给字符串设置不同特征，就可以用不同的方式来指定文档库。根 据上述说明，还可以定义各种不同的字符串特征；该方式不仅能应用于指定文 档库路径，还能应用于其它场合，特别是用来指定特定资源位置的应用场合。 在很多情况下，希望能够用一种新方式来指定相关资源，但又不能或不希望改 变现有的协议或函数，这时就可以通过在字符串中设置不同特征的方式来指定， 这种方法具有最好的通用性，这是因为，无论何种协议或函数，只要支持磁盘 文件名或URL,就支持字符串。
1.3返回值
如果成功，则在UOML—RET中包含一个"handle"子元素，记录句柄2关闭(UOML—CLOSE),参见图12。 2.1属性无。 2.2子元素
2.2.1 handle:对象句柄，是一个字符串表示的对象的引用指针。
2.2.2 db—handle:文档库句柄，字符串表示的文档库的引用指针。 2.3返回值无返回值。
3 UOML—GET获取，参见图13。 3.1属性
3.1.1 usage:用途，为"GetHandle"(获取指定对象句柄)、"GetObj"(获 取指定对象数据)、"GetPageBmp"(获取版面位图)中的一个。 3.2子元素
3.2.1 parent:父对象句柄，usage属性为"GetHandle"时使用。
3.2.2 pos:位置顺序号，usage属性为"GetHandle"时使用。
3.2.3 handle:指定对象的句柄，当usage属性为"GetObj"时使用。
3.2.4 page:需要显示的页面的句柄，当usage属性为"GetPageBmp"时使用。
3.2.5 input:描述了对输入页面的约束，其中可以指定显示一层或者多层 的内容(可以显示的层一定是当前角色有权限访问的层)；也可以通过指定Clip 区域来指定显示区域的大小。当usage属性为"GetPageBmp"时使用。
3.2.6 output:描述了版面位图的输出方式.，当usage属性为"GetPageBmp" 时使用。
3.3返回值
3.3.1 当usage属性为"GetHandle"时，执行成功时在UOML—RET中包含 一个"handle"子元素，记录parent下第pos个子对象的句柄。
3.3.2 当usage属性为"GetObj"时，执行成功时在UOML—RET中包含一个 "xobj"子元素，含有handle对象的数据的xml表示。
3.3.3 当usage属性为"GetPageBmp"时，执行成功时在output指定位置输出版面位图。
4 UOML—SET设置，参见图14。 4.1属性无。
4.2子元素
4.2.1 Handle:设置对象的句柄。
4.2.2 xobj:对象的描述。 4.3返回值无返回值。
5 UOML—INSERT插入，参见图15 5.1属性无。
5.2子元素
5.2.1 parent:父对象句柄。
5.2.2 xobj:对象的描述。
5.2.3 pos:插入位置。
5.3返回值如果执行成功，则将xobj参数表示的对象，插入到parent中 成为其第pos个子对象，并在UOML—RET中包含一个"handle"子元素，表示新 插入对象的句柄。
6 UOML—DELETE 删除，参见图16 6.1属性无。
6.2子元素
6.2.1 handle:需要删除的对象的句柄。 6.3返回值无返回值。
7 UOML—QUERY检索查询，参见图17 7.1属性无。
7.2子元素
7.2.1 handle:需要查询的文档库句柄。
7.2.2 condition:查询条件。
7.3返回值如果成功，在UOML—RET中包含一个"handle，，子元素代表查询结果的句柄， 一个"number"子元素代表查询结果的数量，可以用UOML—GET 来获取每一个查询结果。 UOML对象包括
文档库(UOMLDOCBASE)、 文档集(UOML_DOCSET)、 文档 (UOML一DOC)、 页(UOML—PAGE)、 层(UOML—LAYER)、 对象组 (UOMLOBJGROUP)、文字(UOMLTEXT)、图像(UOMLIMAGE)、直线 (UOML—LINE)、 曲线(UOML—BEIZER)、 圆弧(UOML—ARC)、 路径 (UOML—PATH )、源文件(UOMLSRCFILE)、背景色(UOML—BACKCOLOR)、 前景颜色(UOMLCOLOR)、 ROP(UOML—ROP)、字符尺寸(UOML—CHARSIZE)、 字体(UOML—TYPEFACE)。
下文以UOML—DOC、 UOML—TEXT和UOML—CHARSIZE为例i兌明其定 义方式
1 UOML—DOC 1.1属性无。 1.2子元素
1.2.1 metadata:元凄t据。
1.2.2 pageset:各页面。
1.2.3 fontinfo:嵌入字库。
1.2.4 navigation:导航信息。
1.2.5 thread:导读信息。
1.2.6 minipage:孩i缩片反面。
1.2.7 signiture:数字签名。
1.2.8 sharesource:共享资源。
2 UOML—TEXT 2.1属性
2.1.1 Encoding: 文字编码方式。 2.2子元素2.2.1 TextData: 文字内容。
2.2.2 CharSpacingList:对非等间距文字的字间距列表。
2.2.3 StartPos:起点位置。 3 UOML—CHARSIZE
3.1属性
3丄1 width:字符宽度。 3丄2 height:字符高度。 3.2子元素无。
以此类推，可以用同样的方法来描述所有的UOML对象。当应用软件对文 档库进行操作时，由上述UOML动作与UOML对象依照XML语法生成相应 的UOML命令，将该UOML命令发给文档库系统，即代表向文档库系统发出 了相应操作指令。
例如，对创建文档库操作,可以用以下命令来完成
<UOML—OPEN create="true">
<path val="f:\\data\\docbasel .sep'V〉
</UOML—OPEN〉
对创建文档集操作，可以用以下命令来完成 <UOML—INSERT >
<parent val= "123.456.7897〉
<pos val="17>
<xobj>
<docset/> </xobj>
</UOML—INSERT>
需要说明的是，虽然UOML是用XML定义的，但为了显得更加简洁，在 前面省略了类似"< xml version=" 1.0" encoding="UTF-8" >，，以及"xmlns:xsi: "http:〃www.w3.org/2001/XMLSchema-instance""之类的常规XML格式，只要是 熟悉XML语法的实施者都可以在实施过程中自行添加。也可以不用XML方式定义命令串，例如改用类似PostScript那样的方式， 这才羊上例变成
1, "f:WdataWdocbasel.sep", /Open /docset, 1, "123.456.789" ， /Insert
根据同样的思路，还可以定义出其它类型的命令串格式，甚至还可以不用 文本方式，而用二进制方式来定义命令串。
现在介绍对每一个对象的每一个操作都用一个命令来表示的方式的一个具 体实例，在本实例中，用"UOML—INSERT—DOCSET"来表示插入一个文档集， 用"UOML—INSERT—PAGE"来表示插入一页，以这样的方式来定义每个命令 UOML—INSERT—DOCSET在文档库中创建一个文档集 属性无 子元素
parent: 文档库句柄 pos:插入位置
返回值如果执行成功，则在UOML一RET中包含一个"handle"子元
素，表示新插入文档集的句柄 这才羊上例就变为 <UOML—INSERT—DOCSET >
〈parent val="123.456.7897>
<pos val=T/> </UOML—INSERT—DOCSET >
用这种方法定义命令格式需要对每个对象的每种合法操作都单独定义一条 命令，缺点是比较繁瑣。
现在介绍用函数调用的方式来实现接口标准的实例，在该实例中，通过上 接口调用下接口的接口函数的方式来发送操作指令给文档库系统。以下以C++ 语言为例说明，该实例称为UOI。在该实例中，定义了 UOI一Object作为所有对 象的基类，为每个动作定义了一个函数，该函数的参数可以是对基类的指针或引用，这样该函数就可适用于所有对象。
先定义一个UOI返回值结构 struct UOI—Ret {
BOOL m—bSuccess;
CString m—Errlnfo;
};
定义所有UOI对象的基础类
class UOI—Object {
public:
enum Type {
TYPE—DOCBASE，
TYPE—DOCSET，
TYPE—DOC, TYPE—PAGE, TYPE—LAYER, TYPE—TEXT, TYPE—CHARSIZE,
Type m—Type;
UOI_Object(); virtual UOI—Object(); static UOI—Object Create(Type objType);
};
然后定义如下几个uoi函数，与"操作动作+操作对象，，方式实例中的几个
UOML动作相对应
UOI—RET UOI—Open(char *path， BOOL bCreate, HANDLE *pHandle); UOI—RET UOI—GloseCHANDLE handle, HANDLE db—handle);UOI—RET UOI—GetHandle(HANDLE hParent， int nPos, HANDLE *pHandle); UOI—RET UOI—GetObjType(HANDLE handle, UOI—Object ::Type *pType); UOI—RET UOI—GetObj(HANDLE handle, UOI—Object *pObj); UOI—RET UOI—GetPageBmp(HANDLE hPage， RECT rect, void *pBuf); UOI—RET UOI—SetObj(HANDLE handle, UOI—Object *pObj); UOI—RET UOI—Insert(HANDLE hParent, int nPos， UOI—Object *pObj, HANDLE *pHandle = NULL);
UOI—RET UOI—Delete(HANDLE handle);
UOI—RET UOI—Query(HANDLE hDocbase， const char *strCondition, HANDLE承phResult);
然后定义各UOI对象，依然以U01—Doc、 UOI—Text和UOML—CharSize为
例i兌明
class UOI一Doc : public UOI一Object { public:
UOI—MetaData m一MetaData;
int m—nPages;
UOI—Page **m_pPages;
int m一nFonts;
UOI—Font **m_pFonts; UOI—Navigation m—Navigation ;
UOI—Thread m—Thread ;
UOI一MiniPage *ip_pMiniPages;
UOI—Signature m—Signature ;
int m—nShared j
UOI—Obj *m_pShared;
UOI—Doc();
virtual UOI一Doc();
};class UOI—Text: public UOI—Object {
public:
enum Encoding { ENCODE—ASCII, ENCODE一GB 13000, ENCODE—UNICODE,
Encoding m一Encoding;
char *m_pText;
Point m一Start;
int *m—CharSpace ;
UOI一Text();
virtual UOI—Text();
};
class UOI一CharSize : public UOI一Object { public :
int m—Width ;
int m一Height j
UOI—CharSize(); virtual ~UOI—GharSize();
};
以下说明UOI的使用方法。首先是创建文档库操作
ret = UOI—Open("f:WdataWdocbasel.sep", TRUE, &hDocBase);
然后是构建一个创建新对象的函数
HANDLE InsertNewObj (HANDLE hParent, int nPos， UOI一Object ::Type type) {
UOI—Ret ret;HADNLEhandle ;
UOI—Obj *pNewObj = UOI—Obj::Create(type); if(pNewObj==NULL)
return NUIX; ret = UOI—Insert(hParent, nPos, pNewObj， &handle); delete pNewObj;
return ret.m_b Success handle : NULL;
然后是直接获取对象的函数 UOI—Obj *GetObj(HANDLE handle)
UOI—Ret ret;
UOI一Object ::Type type; UOI—Obj *pObj;
ret = UOI—GetObjType(handle, &type); if ( !ret. m一bSuccess )
return NULL; pObj = UOI一Obj::Create(type); if(pObj==NULL)
return NULL; ret = UOI—GetObj(handle, pObj); if ( !ret. m—bSuccess ) {
delete pObj;
return NULL;
return pObj;
在对每一个对象的每一种操作都定义一个接口函数的方式中，插入文档集 的操作指令就是上接口以下列方式调用下接口的接口函数来发送给文档库系统UOI—InsertDocset(pDocbase, 0);
在封装各个对象类(如文档库类)的方式中，把该对象可以进行的操作定 义成该类的方法，^:
class UOI—DocBase : public UOI—Obj
public:
/承！
* \brief 创建文档库
* \param szPath: 文档库全路径
* \param bOverride:是否覆盖原文件
* Veturn UOI—DocBase对象
承/
BOOL Create(const char *szPath, bool bOverride = false);
* \brief 打开文档库
* \param szPath:文档库全-各径
* \retum UOI—DocBase对象
承/
BOOL Open(const char承szPath);
* \brief 关闭文档库
* \pamm 无
* \return 无
void Close();
/"
* \brief 获取角色列表* \param 无
* \retum UOI—RoleList对象
* \sa UOI—RoleList
承/
UOI—RoleList GetRoleList();
/承1
* \brief 存储文档库
* \param szPath:存储文档库全路径
* \return 无
承/
void Save(char *szPath = 0);
* \brief 插入文档集
* \param nPos:插入文档集的位置
* \retum UOI—DocSet对象
* \sa UOI—DocSet
氺/
UOI—DocSet InsertDocSet(int nPos);
* \brief 获取指定索引的文档集
* \param nindex:文档列表的索引号
* \return UOI—DocSet对象
* \sa UOI—DocSet
承/
UOI—DocSet GetDocSet(int nindex); /承1
* \brief 获取文档集的总数* \param 无
* \retum 文档集个凄史 */
int GetDocSetCount(); /*!
* \brief 设置文档库的名称
* \param nLen: 文档库名称长度
* \param szName: 文档库名称
* \return 无
*/
void SetName(int nLen， const char* szName); /*!
* \brief 获取文档库名称长度
* \param 无
* Veturn 长度
*/
int GetNameLen(); /*!
* \brief 获取文档库名称
* \param 无
* \retum 文档库名称 */
const char* GetName();
* \brief 获取文档库id长度
* \param 无
* \return 长度
*/int GetIDLen();
/承！
* \brief 获取文档库id
* \param 无
* \return id
承/
const char* GetID();
//!构造函数
UOI—DocBase();
〃！析构函数
virtual UOI—DocBase();
};
这样插入文档集的操作指令就是上接口以下列方式调用下接口的接口函数
来发送给文档库系统的
pDocBase.InsertDocset(O);
还可以用同样的方法为Java、 C#、 VB、 Delphi等各种编程语言开发的应用 软件设计各种不同的接口标准。
只要在接口标准中不含有与特定的操作系统(如WINDOWS, UNIX/LINUX、 MACOS、 SYMBIAN)或特定的硬件平台(如x86CPU、 MIPS、 POWER PC等)相关连的特征，该接口标准就可以具有跨平台性，使得不同平 台上运行的应用软件和文档库系统都可以统一使用同样的接口标准，特别是可 以让一个平台上运行的应用软件可以调用另 一个平台上运行的文档库系统来才丸 行相应操作。例如，应用软件部署在客户端，使用的是PC机，Windows操作 系统，文档库系统部署在服务器端，使用的是大型机，Linux操作系统，但应 用软件依然可以像调用本地文档库系统一样调用服务器上的文档库系统来执行 相应文档操作。
如果在接口标准中不含有与特定编程语言相关的特征，则该接口标准还 能做到与编程语言无关。可以看出，用命令串的方式容易构造与平台无关、与编程语言无关的接口标准，更具有通用性。特别是用XML来构造命令串 的话，由于目前在各种不同平台、不同编程语言都存在易于获得的XML生 成解析工具，因此不仅该接口标准具有很好的跨平台性和与编程语言无关 性，也非常便于工程师开发上接口单元和下接口单元。
以上列举了多种接口标准的实现方法，按照类似的思路设计的更多种类的 接口标准也包含在本发明的保护范围之内。
应该理解，可以在上述实例的基础上按同样的思路增加操作指令，也可以 筒化操作指令，特别是文档模型被简化时操作指令也会相应被简化。最简化情 况下只有文档的创建、页面的创建、各版面对象的创建这几个操作指令。
文档操作处理
现在，参见图1,继续描述依照本发明一优选实施例的文档处理系统的工 作过程。
应用软件是包含符合接口标准的上接口单元的软件，例如Office软件、内 容管理、资源采集等。任一应用软件在需要对文档进行操作时，依照前述方法 将指令传递给文档库系统，文档库系统根据指令来完成具体操作过程。
文档库系统可以自由地存储、组织文档库数据，例如可以把一个文档库的 文件全部都存储在一个磁盘文件中；可以一个文档对应一个磁盘文件，利用操 作系统中的文件系统功能实现多文档组织；也可以一页对应一个^兹盘文件；还 可以完全抛开梯:作系统，在^f兹盘上留出一块空间后直接对^磁道、扇区进行管理。 对文档库数据的存储格式，可以用二进制格式保存，可以用XML,还可以用二 进制XML。页面描述语言(定义页面上的文字、图形、图像等对象的方法)可 以采用PostScript,可以采用PDF、 SPD (书生公司使用的页面描述语言)，当 然也可以采用自定义的任何页面描述语言，只要其符合统一的接口标准。
例如，可以用XML来描述文档库数据，当文档模型是层次型的时候，可 以完全对照建立相应的XML树。执行创建操作时就在XML树中增加一个结点， 执行删除操作就删掉相应结点，执行设置操作就设置相应结点的属性，执行获 取操作就取出相应结点的属性并返回给应用软件，执行查询操作时就遍历相关结点查找。
以下是该实施例的进一步说明
1. 用XML来描述每个对象。也就是说，为每个对象都建立了一个对应的 XML树。有的对象属性比较简单，其对应的XML树就只有根结点，有的对象 比较复杂，其对应的XML树还有子结点。具体描述方法可以参见前面用XML 来定义操:作对象的说明。
2. 当新建一个文档库时就新建一个根结点为文档库对象的XML文件。
3. 每当在文档库中插入一个对象时，如文字对象，就将该对象对应的XML 树插入到插入位置的父结点(如层)之下。这样，文档库中的每个对象都在文 档库为根结点的XML树中有一个对应的结点。
4. 当删除一个对象时，就删除该对象对应的结点，其下属所有子结点也都 被删除。删除过程是从叶子结点开始自下而上遍历的。
5. 设置一个对象属性时，将该对象对应的结点的属性设置成该属性。如果 该属性是用子结点表示的，则设置对应的子结点。
6. 获取一个对象属性时，访问该对象对应的结点，根据该结点的属性和子 结点获得该对象的属性。
7. 获取一个对象的句柄时，返回该对象对应结点的XML路径。
8. 复制一个对象(如页面)到指定位置时，就将该对象对应的结点开始的 整个子树都复制到目标位置对应的父结点(如文档)之下。如果是复制到另一 个文档库中，则需要将该子树引用的对象(如嵌入字库)也一起复制过去。
9. 执行获取版面信息指令时，先生成一个指定位图格式的空白位图，其尺 寸和指定区域相同，然后遍历指定页面的所有版面对象，凡是位于指定区域内
(包括只有一部分在该区域内)的版面对象，都解释其含义，并在版面上相应 体现。具体过程虽然比较复杂比较专业，但均属于现有RIP技术范畴，不在此赘述。
文档安全处理
在创建角色对象时，生成一对随机7>私钥对(例如512位的RSA密钥)，将公钥存储在角色对象中，将私钥返回给应用软件。
当应用软件登录时，随机生成一块(例如128字节)数据，用相应角色对 象中的公钥加密该数据发给应用软件，应用软件解密后比较验证，如果正确则 表明应用软件确实拥有该角色对应的私钥，登录成功。为保险起见，该认证过 程可以重复三次，三次全部通过才算登录成功。
当对某一对象进行签名时，也就是对其对应的结点开始的子树进行签名。 为了能够使签名不受具体物理存储方式的影响，需要先做一个正则化，使得逻 辑上等效的变化(例如存储位置的改变导致相应指针的变化)不会影响签名有
岁支性。该正则4b的方法如下
按深度优先遍历以目标对象为根节点的子树中的各个节点(即目标对象及 其各个子对象)，按照遍历顺序依次计算每个节点的正则结果并连接起来。
其中，对子树的某一节点计算正则结果的方法为先计算该节点的子节点 数的HASH值，然后再依次计算该节点类型及其各个属性的HASH值并按顺序 连接在该节点的子节点数的HASH值的后面，再计算该连接结果的HASH值， 得到该节点的正则结果。如果需要对子树中的某个节点引用的对象也一起做签 名，则可以将该节点引用的对象也作为该节点的一个子节点来处理，方法同上。
这里不再赘述。
在上述正则化过程中，可以把计算一个节点正则结果的方法改成如下方案 将该节点的子节点数、类型及其各属性用分隔符隔开后按照顺序连接起来，计 算该连接的结果的HASH值，得到该节点的正则结果。还可以把计算一个节点 正则结果的方法改成如下方案将该节点的子节点数、类型及其各属性的长度 用分隔符隔开后按照顺序连接起来，再与子节点数、类型、各属性连接起来， 即得到该节点的正则结果。总之，计算一个节点正则结果的方法可以采用以下 各种方案中的任意一种对树的某一节点，其子节点数、类型、各属性，子节 点数/类型/各属性的长度(可选的)，原值或经过特定变换(如HASH、压缩), 按照预定顺序连接起来(直接连接或用分隔符隔开)。上述预定顺序的意思是，子节点数长度、类型长度、各属性长度、子节点 数、类型、各属性可以按任意顺序排列，只要是预定的顺序即可。
另外，在遍历子树中各个节点时，既可以釆用深度优先遍历也可以采用宽 度优先遍历。
不难给出上述方案的各种变化方式，如每个结点的子结点数用分隔符隔开 后按照深度优先的顺序连接起来，再与各结点其它数据的正则结果连接起来。 总之，只要对该子树中的所有结点的子结点数、类型和各属性，按照确定的方 法排列在一起就属于本实施例的变化。
当对某一对象设置权限时，最简单的实现方式是简单记录各角色对该对象 (及其子对象)的权限，并在今后各角色访问时加以比较，符合权限的则允许 相应操作，否则报错返回。更好的实现方式是对相应数据加密，并用密钥来控 制权限，如果该角色没有相应密钥就没有对应的权限，这种方式抗攻击能力要
更强。具体方案为
a) 对受保护的数据区域(通常为一个子树，对应某对象及其所有子对 象)，有一对对应的PKI密钥对，用其中的加密密钥对该数据区域进行加密。
b) 对具有读权限的角色，授予其解密密钥，该角色可以用该密钥解密该 数据区域，从而正确读取这些数据。
c) 对具有写权限的角色，将授予其加密密钥，该角色可以将修改后的数
据用该密钥加密，〃Mv而可以正确写入该区域的凄t据。
d) 鉴于PKI的加密/解密效率较低，为提高运行效率，也可以用对称 密钥来对该数据区域加密，加密密钥用于对该对称密钥进行加密，解密密钥用 于解密经过加密后的密钥数据，从而获得正确的对称密钥。为防止只有读权限 的角色在获得对称密钥后用其修改数据，可以用加密密钥来对该数据区域进行 数字签名，每次拥有写权限的角色修改该数据区域后都重新做一次签名，从而 确保数据不会被没有写权限的角色篡改。
e) 当授予某一角色加密密钥或解密密钥时，可以用该角色的公钥对该密 钥加密后存储，这样只有拥有该角色的私钥时才能取出该密钥需要说明的是，本发明中所说明的文档安全技术，如基于角色的权限管理、 角色的认证方式、多重角色登陆、对树结构的正则化技术、细粒度的权限管理 单元、基于加密的权限设置等，都不仅适用于本发明所述的文档处理系统，还 可以运用于更为广泛的其它应用场合。
对层的管理
在本发明中，为了使本文档处理系统能很好地模拟纸张的特性，提供了一 种"只加不改"的技术方案。也就是说，每个应用软件都只在现有文档内容基础 上添加新的内容，但不修改、不删除已有的内容，使文档的一个页面就象一张 纸一样，可以由不同的人用不同的笔在纸上不断写写画画，但谁都不能》务改、 删除已有内容。具体方法是每一个应用软件在编辑其它软件生成的文档时，都 在现有文档基础上新增加一层，将本软件新编辑的内容都放到这一层中，不修 改和删除前面各层的内容。这样，每个文档的每一层只由一个应用软件来管理 和维护，其他应用软件不能对该层进行编辑。由于现有社会就是基于纸张来运 转的，因此只要能符合纸张的特性就能满足现有应用的需求，具备足够的实用 价值。
为了确保每一层内容在生成后没有被修改、删除，可以利用每一层的数字 签名对象。数字签名可以是对本层内容进行签名，优选地，可以是对本层以及 本层之前生成的所有层的内容一起签名。签名以后并不妨碍对文档做进一步的 批注等编辑，只要新的内容是位于新建的层，没有修改破坏签名时存在的各层， 签名依然是有效的，但签名者只对签名以前的内容负责，不对签名以后的内容 负责。这是一个非常符合应用需求的技术方案，具有很大的实用价值。相比之 下，现有的其它技术或者签名后不允许编辑，或者编辑后(尽管是"只加不改" 的编辑)签名被破坏。
前述技术方案不允许修改文档中的已有内容，即使不考虑与纸张特性的兼 容以及数字签名问题，需要修改的话也只能做版面级编辑，即对每个版面对象 的编辑(增、删、改)都不会对其它版面对象产生影响(这是由于通用文档才莫
型是基于可见部分为基础构建的，不包含大量不可见的、关于版面对象之间的关系，因此修改任何一个版面对象时，其它版面对象不会产生相应的调整，例 如删掉一个字，就会在其位置留下空白，右边的文字不会自动左移)。如果用 户需要对文档中的已有内容进行编辑，并且还希望能像在原来那样编辑的话， 有一个技术方案可以很好地满足这个应用需求。该方案是当应用软件完成初始
编辑时，除了新建一层存;^文当前编辑的内容外，还将源文件(按照应用软件自 有的格式存储，记录了各对象之间完整关系的文件，例如.doc文件)嵌入到文
档中。当下次需要进行继续编辑时，/人文档中取出该源文件，并使用该源文件 继续编辑。编辑完成后清除该软件所管理的那一层，重新生成该层的内容，并 继续将新修改的源文件嵌入到文档中。
具体方法如下
1. 应用软件第一次处理该文档时，新建一层，将新编辑内容对应的版面对 象插入到新建层中，同时用自身格式另存一J分新编辑的内容(即源文件)。
2. 在文档对象中新建一个源文件子对象，用来嵌入源文件(例如用二进制 数据的方式整体嵌入)，并记录是哪一层对应该源文件对象。
3. 用同 一应用软件再次编辑该文档时， >夂人对应的源文件对象中取出对应的 源文件。
4. 使用该源文件继续编辑该层内容。由于该源文件是该应用软件自身的格 式，可以按照该应用软件自身的功能继续对该层内容进行编辑。
5. 再次编辑结束后，根据新编辑后的结果更新该层内容(例如用全部清除 后全部重新生成的方式)，同时将新^修改后的源文件重新嵌入到文档对象中。
6. 如此循环往复，就可以用原有应用软件按照原有方式对文档中的已有内 容进行编辑。
采用上述技术方案，可以最大程度地实现文档的互操作性。在应用软件、 文档都采用本发明技术时，在有足够安全权限的前提下，可以实现以下功能
1. 对任何文档，用任何应用软件都可以正确打开、显示、打印。
2. 对任何文档，用任何应用软件都可以新添加任何内容，而且不会破坏文 档已有签名。3. 对任何文档，在不必考虑文档已有签名(没有签名或者虽有签名但允许
4. 对任何文档，使用文档已有内容的原始编辑软件可以对该内容进行正常
由此可见，通过本发明中对层的管理，对文档的管理、互操作、安全设置 都带来极大的便利。
下面以A软件创建一个文档并且B软件对其进行编辑为例说明其工作过 程。在本例中选用UOI作为接口标准
1. A软件发出指令,创建文档库c:\sample\mydocbase.sep，将其句柄存放 在hDocBase:
UOI—Open("c:WsampleWmydocbase.sep", TRUE, &hDocBase);
2. A软件发出指令,在文档库hDocBase中新建文档集，将其句柄存放在 hDocSet:
hDocSet = InsertNewObj(hDocBase, 0, UOI—Obj:: TYPE—DOCSET);在本实例中， 该文档库中只有一个文档集，即第一个文档集；
3. A软件发出指令,在文档集hDocBase中新建文档，将其句柄存;^文在 hDoc:
hDoc = InsertNewObj(hDocSet, 0, UOI—Obj:: TYPE—DOC);在本实例中，该文档 集只有一个文档，即第一个文档；
4. A软件发出指令，在文档hDoc中新建一页，版心大小是宽w,高h,将 其句柄存放在KPage:
UOI—Page page; page.size.w画 w; page.size.h =
UOI_Insert(hDoc, 0, &page, &hPage);在本实例中，该文档中只有一页，即第一
页；
5. A软件发出指令，在页hPage中创建一层，将其句柄存放在hLayer:hLayer = InertNewObj(hPage, 0, UOI—Obj::TYPE—LAYER);在本实例中，该页只 有一层，即第一层；
6. A软件发出指令，设置字号为s: UOI—CharSize charSize; charSize.m—Width ■— charSize.m—Height — s;
UOI—Insert(hLayer, 0, &charSize);在本实例中，该层的第一个版面对象是字号
对象；
7. A软件发出指令,在坐标(xl,yl)位置插入文字串"书生意气挥斥方遒" UOI—Text text;
text.m_pText = Duplicate("书生意气挥斥方遒")； text.m—Encoding = UOI—Text:: ENCODE—GB13000; text.m—Start.x = xl; text.m一Start.y = yl;
UOI—Insert(hLayer, 1, &text);在本实例中，该层的第二个对象是文字对象；
8. A软件发出指令,关闭文档库hDocBase: UOI—Close(hDocBase);
B软件发出指令,打开文档库c:\sample\mydocbase.sep，将其句柄存放在
hDocBase:
UOI—Open("c:WsampleWmydocbase.sep", FALSE, &hDocBase);
B软件发出指令,获取文档库hDocBase第一个文档集的指针，将其句柄存 放在hDocSet:
UOI—GetHandle(hDocBase, 0, &hDocSet);
9. B软件发出指令,获取文档集hDocSet第 一个文档的指针，将其句柄 存放在hDoc:
UOI—GetHandle(hDocSet, 0, &hDoc);
10. B软件发出指令,获取文档hDoc第一页的指针，将其句柄存放在 hPage:
UOI—GetHandle(hDoc, 0, &hPage);11. B软件获取该页版面位图，用于显示该页
UOI—GetPageBmp(hPage， rect, buf);
12. B软件发出指令,获取hPage第一层的指针，将其句柄存放在hLayer: UOI—GetHandle(hPage, 0, &hLayer);
13. B软件发出指令，获取第一个版面对象的句柄hObj: UOI—GetHandle(hLayer, 0， &hObj);
14. B软件发出指令,获取hObj的类型 UOI—GetObjType(hObj， &type);
15. B软件发现这是一个字号对象，获取该对象 UOI—GetObj(hObj, &charSize);
16. B软件将字高放大一倍 charSize.m—Height *= 2; UOI一SetObj(hObj, &charSize);
B软件重新获取版面位图并显示，这时会发现屏幕上的"书生意气挥斥方 遒"变成长体字了 。
本发明改变了从用户界面到文档存储都由一个软件来完成的现状，将其划 分为应用层和文档库系统层，并定义一个规范两层之间交互的接口标准，还可 以进一步构建一个符合该接口标准的接口层。文档库系统是具备各种文档操作 功能的通用技术平台，应用软件要对文档进行操作时就通过该接口层来向文档 库系统发出相应指令，文档库系统根据该指令执行相应操作。这样，只要各应 用软件和各文档库系统都遵循同样的标准，不同应用软件就可以通过同 一个文 档库系统对同一文档操作，即可实现对文档的互操作。同样，同一个应用软件 也可以通过不同文档库系统对不同文档进行操作，而不用分别对每种文档格式 都进行单独开发。
本发明还包括一个通用文档模型，该模型能与各应用软件所需要处理的文 档相符合。接口标准就是基于该文档模型来确定的，这样才能实现不同的应用 软件都可以通过接口层来对文档进行操作。该通用文档^t型也适用于各种文档格式，这样同 一个应用软件才可以通过接口层来对不同文档格式进行操作。接口标准定义了基于该通用文档模型对文档进行操作的各种指令，以及应用软件向文档库系统发送指令的方式。文档库系统具备实现这些指令的功能，以供应用软件调用。该通用文档模型还包括由多个文档组成的文档集、文档库和文档仓库等层次，接口标准中也包含对多文档的组织管理、查询检索、安全控制等指令。该通用模型还包括将页由具有上下顺序的层组成，接口标准中也包含对层 的各种操作指令，以及对一个文档某一层所对应源文件的存储和提取。文档库系统还具备对文档的信息安全管理控制功能，如基于角色的细粒度 权限管理，并在接口标准中定义了相关的操作指令。依照本发明，使得应用层和数据处理层分离。这样应用软件不再直接跟具 体的文档格式打交道，文档也不再与特定应用软件绑定，从而使得同一文档能 在不同的应用软件之间通用，同一应用软件也能对不同文档进行操作，实现了文档的互操作；整个文档处理系统还具备多文档处理功能，而不局限在单文档 处理；将页分成多层后，可以实现对不同层实施不同管理和控制，更便于不同 应用软件对同 一页的操作(可以设计成不同应用软件管理和维护不同层)，为以 源文件方式进行编辑提供了便利，也是一种很好的保留历史痕迹的方式；通过 将信息安全集成在文档处理的核心层，可以消灭安全缝隙，还能使安全机制与 文档操作紧密地结合为一体，而不是可以分离的两个it块，同时有更多的空间 部署安全管理技术，相关代码也能隐藏得更深，能更有效地防御非法攻击，提 高安全可靠度，另外还能提供细粒度的安全管理手段，如更多的权限类别，更 小的管理单元。下面，参照图18描述依照本发明的文档操作系统执行一操作的一个实例。 在该实例中，应用软件通过统一的接口标准(例如UOML接口 )请求对文档的 操作。文档库系统可能会有不同厂商的不同型号，但是对于应用开发厂商来说 面向的都是同一个接口标准，因此都可以与之配套使用。RedOffice、 OCR、网 页生成软件、乐语编辑软件、书生阅读器、Office编辑软件、其他阅读器等通过UOML接口指示文档库系统进行操作，文档库系统可以有多个，在图中显示 为文档库系统1 、文档库系统2和文档库系统3 ，文档库系统根据UOML发来 的统一标准指令对符合通用文档模型的文档进行操作，例如创建、保存、显示、 呈现文档。在本发明中，不同的应用软件可以同时或不同时调用同一个文档库 系统，同一应用软件可以同时或不同时调用不同的文档库系统。依照本发明，使得应用层和数据处理层分离，使得同一文档能在不同的应 用软件之间通用，使不同应用软件之间具有良好的文档互操作性。依照本发明，形成产业分工，减少重复开发，并更加专业、完备、正确； 对文档的基本操作都在文档库系统中处理，各应用软件不必重复开发。而且由 于文档库系统是由专业厂商开发，相关技术的专业性、完备性、正确性较有保 障，而且应用软件厂商和用户可以选择估支的最好的一家文档库系统厂商，从而 保证处理效果的正确性和 一致性。依照本发明，提供多文档甚至海量文档的管理机制，使文档之间能够有效 组织起来，便于检索、查询、保管，便于嵌入较强的信息安全机制。依照本发明，提供更好的安全机制，可以设置多种角色，细粒度地设置每 个角色的权限。其中细粒度是双重的， 一方面可以对整个文档或文档的一个细 微之处进行权限设置，另一方面可以设置种类非常多的权限，而不仅仅是传统 的读/写/不可访问三级。依照本发明，鼓励创新，合理竟争。形成合理的产业分工后，各文档库系 统厂商和各应用软件厂商就会在领域展开竟争，而不会再出现Microsoft Word 一样靠文档格式来垄断应用软件的情形发生。各文档库系统厂商也可以在标准 之外增加新的功能以吸引用户，标准并不会对创新形成束缚。依照本发明，便于优化性能，有更好的可移植性和可伸缩性。无论是什 么平台，什么样的性能，都可以遵循同样的调用接口 ，使得在不改变接口标 准的情况下可以不断优化性能，并移植到不同的平台。以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本 发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。
权利要求
1、一种文档处理方法，其特征在于，包括应用软件发送指令到平台软件，以对抽象非结构化信息进行操作；平台软件接收到来自所述应用软件的指令，根据所述指令，对与所述抽象非结构化信息对应的存储数据执行所述操作；其中，所述抽象非结构化信息与所述存储数据的存储方式无关。
2、 如;k利要求1所述的方法，其特征在于，所述抽象非结构化信息不具有 存储。
3、 如权利要求l所述的方法，其特征在于，所述抽象非结构化信息包括可 视化信息、和/或流媒体信息、和/或多维信息、和/或安全控制信息、和/或文档 组织4言息、和/或交互4言息。
4、 如权利要求l所述的方法，其特征在于，通过发送命令串或调用函数来 发送指令。
5、 如权利要求l所述的方法，其特征在于，所述存储数据为一个或多个磁 盘文件、部分磁盘文件、数据库的一个或多个字段、或磁盘分区的一个区域。
6、 如权利要求l所述的方法，其特征在于，所述抽象非结构化信息包括多 个页的可视化信息。
7、 如权利要求l所述的方法，其特征在于，所述抽象非结构化信息符合预 定义文档^t型。
8、 如权利要求l所述的方'法，其特征在于，所述预定义文档模型为树形结 构，并且包括至少文档对象、页对象以及用于描述版面的对象。
9、 如权利要求8所述的方法，其特征在于，所述用于描述版面的对象可以 是文字对象、图片对象和图形对象中的任一项或任几项的组合。
10、 如权利要求9所述的方法，其特征在于，所述用于描述版面的对象还 可以是状态对象、文字对象、直线对象、曲线对象、圓弧对象、路径对象、渐 变色对象、图像对象、流媒体对象、元数据对象、批注对象、语义信息对象、源文件对象、脚本对象、插件对象、二进制数据流对象、书签对象以及超链接 对象中任一项或任几项的组合。
11、 如权利要求8所述的方法，其特征在于，所述预定义文档模型进一步包括文档库对象，所述文档库对象包括至少一个文档对象；或者，所述预定义^t型进一步包括文档库对象和文档集对象，其中所述文档库对 象包括至少一个文档集对象，所述文档集对象包括至少一个文档对象和\或至少 一个文档集对象。
12、 如权利要求8所述的方法，其特征在于，所述预定义文档^t型进一步 包括层对象，所述页对象包括至少一个层对象，所述层对象包括至少一个用于 描述版面的对象。
13、 如权利要求12所述的方法，其特征在于，所述预定义文档模型进一步 包括对象组对象，所述层对象包括至少一个对象组对象，所述对象组对象包括 至少一个用于描述版面的对象。
14、 如权利要求7所述的方法，其特征在于，所述预定义文档^f莫型进一步 包括角色对象以及角色的访问权限。
15、 如权利要求14所述的方法，其特征在于，所述角色的访问权限包括所 述角色针对所述抽象非结构化信息的至少一个对象的访问权限。
16、 如权利要求l所述的方法，其特征在于，所述指令符合操作动作+操 作对象的标准，以指示一个4喿作。
17、 如权利要求16所述的方法，其特征在于，所述操作包括获取信息、 设置对象属性、插入对象、删除对象以及查询。
18、 如权利要求16所述的方法，其特征在于，所述指令按预定义的格式生成。
19、 如权利要求18所述的方法，其特征在于，所述指令包含描述操作动作 和操作对象的字符串。
20、 如权利要求19所述的方法，其特征在于，所述字符串用可扩展标记语 言XML描述。
21、 如权利要求20所述的方法，其特征在于，所述操作动作对应一个XML 元素，所述操作对象通过句柄handle引用。
22、 如权利要求16所述的方法，其特征在于，所述平台软件提供接口函数， 每个接口函数定义针对一个对象的一个操作；所述应用软件通过调用与所述操作动作和操作对象对应的接口函数，发送 所述指令。
23、 如权利要求16所述的方法，其特征在于，所述平台软件提供基于对象 类的方法；所述应用软件通过调用所述对象类的方法发送指令；其中所述对象类由所 述操作对象封装而成，所述对象类的方法对应所述操作动作。
24、 如权利要求l所述的方法，其特征在于，所述平台软件进一步为应用 软件提供操作结果。
25、 —种文档处理系统，其特征在于，包括应用软件，用于发送指令到平台软件，以对抽象非结构化信息进行操作； 平台软件，用于接收到来自所述应用软件的指令，根据所述指令，对与所 述抽象非结构化信息对应的存储数据执行所述操作；其中，所述抽象非结构化信息与所述存储数据的存^f诸方式无关。
26、 一种文档处理方法，其特征在于，包括 第一应用软件发送第一指令到平台软件，以创建第一抽象文档；所述平台软件接收所述第 一指令，创建与所述第 一抽象文档对应的存储数据；第二应用软件发送第二指令到所述平台软件以打开所述创建的存储数据； 所述平台软件接收所述第二指令，打开并解析所述存储数据，生成与所述 存储数据对应的第二抽象文档；其中所述第 一指令与第二指令符合相同的接口标准。
27、 一种文档处理系统，其特征在于，包括第一应用软件，用于发送第一指令到平台软件，以创建第一抽象文档；所述平台软件，用于接收所述第一指令，创建与所述第一抽象文档对应的存储数据；第二应用软件，用于发送第二指令到平台软件以打开所述创建的存储数据； 所述平台软件，进一步用于接收所述第二指令，打开并解析所述存储数据， 生成与所述存储数据对应的第二抽象文档；其中，所述第一指令与第二指令符合相同的接口标准。
28、 一种文档处理方法，其特征在于，包括第一平台软件解析以第一数据格式存储的第二存储数据，生成与所述存储 数据对应的第 一抽象文档；所述应用软件发送第 一指令到所述第 一平台软件，以获取所述第 一抽象文 档的所有信息；发送第二指令到第二平台软件，以创建与所述第一抽象文件相 同或相似的第二抽象文档；所述第二平台软件根据所述第二指令，创建与所述第二抽象文档对应并按 第二数据格式存储的第二存储数据；其中，所述第一指令和第二指令符合相同的接口标准。
29、 一种文档处理系统，其特征在于，包括第一平台软件，用于解析以第一数据格式存储的第一存储数据，生成与所 述存储数据对应的第 一抽象文档；所述应用软件，用于发送第一指令到所述第一平台软件，以获取所述第一 抽象文档的所有信.息；发送第二指令到第二平台软件，以创建与所述第一抽象 文件相同或相似的第二抽象文档；所述第二平台软件，用于根据所述第二指令，创建与所述第二抽象文档对 应并按第二数据格式存储的第二存储数据；其中，所述第一指令和第二指令符合相同的接口标准。
全文摘要
本发明公开了一种文档处理系统和方法，该方法包括应用软件发送指令到平台软件，对抽象非结构化信息进行操作；平台软件接收到来自所述应用软件的指令，根据所述指令，对与所述抽象非结构化信息对应的存储数据执行所述操作；其中，所述抽象非结构化信息与所述存储数据的存储方式无关。本发明的这种系统和方法将应用层和数据处理层分离，有利于产业分工，以及达到文档互操作、信息资源互联互通等有益效果。
文档编号G06F9/44GK101599011SQ20081011445
公开日2009年12月9日 申请日期2008年6月5日 优先权日2008年6月5日
发明者刘宁胜, 王东临 申请人:北京书生国际信息技术有限公司