面向流式办公文档的查询语言

刘旭红，施运梅，侯 霞，李 宁

（1.北京信息科技大学 计算机学院，北京100101；2.北京信息科技大学 网络文化与数字传播北京市重点实验室，北京100101）

0 引 言

采用XML描述的流式办公文档格式繁多，主要包括OOXML［1］、ODF［2］和UOF［3］这3 种 主 要 标 准，如 何 以 尽量统一且简单灵活的方式从这些文档中获取信息，成为亟需解决的问题。为此，人们提出了不同的查询语言和技术。

针对XML文档的查询语言，如XQuery，可以访问流式办公文档［4］；文献 ［5］提出使用XQuery语言实现多种格式文档的数据集成。然而这些查询语言是针对普通的XML数据设计，其查询粒度过细，不能针对段落、节、文字表等功能点进行操作［6］。

为此，一些标准组织机构和厂商都提供了对其相应格式文档访问操作的API，如OOXML API、UOF API和ODF API。这些API将文档操作进行封装，提供了一种比XQuery更简单的方式。API也有一些固有的缺陷，主要体现在如下几个方面：①这些API都依赖于具体的环境，如ODF API依赖于UNO 架构，OOXML API需要VBA／.NET 和Windows环境；②同一标准的不同版本的API也有差异；③API的使用较为困难，对程序员的要求较高［7］。

信息检索技术也可以访问流式办公文档，但其重点是文本检索，而文本经过预处理往往失去了对于信息检索非常重要的文档的内在结构信息［8，9］。例如，我们需要检索论文中的某个段落的内容，使用针对HTML的信息检索技术就很难实现。

综上所述，在流式办公文档领域，缺乏一种简单、统一且无关平台的技术，从不同标准的文档中获取与文档结构相关的信息。为此，本文提出一种针对流式办公文档的查询语言ODQ。

1 ODQ 的设计

1.1 总体设计

为了解决上述问题，在设计ODQ 时，需要遵循下面的原则：

（1）ODQ 应该是一种针对流式办公文档的非过程化的查询语言，不包含分支和循环结构，从而能够方便的嵌入到其它高级编程语言中使用。

（2）从用户的使用需求出发，脱离办公软件，直接操作不同格式的流式办公文档，从而可以方便的应用于各种流式办公文档应用系统中。

（3）通过建立公共文档模型，屏蔽不同办公文档格式之间的差异，提高文档的互操作性。

（4）ODQ 需要涵盖办公文档的常用功能，可以针对元数据、段落、节、文字表、列表等文档结构进行查询、更新和删除操作，满足用户的大部分需求。

（5）ODQ 应该独立于平台和编程语言，与具体应用无关，可以满足多种应用系统对办公文档进行操作的需求。

（6）ODQ 的语法应该尽量简单，以降低学习成本。

综上所述，ODQ 的功能和作用类似于SQL。数据库应用系统通过SQL可以访问不同的数据库管理系统中的数据。类似地，对于信息检索、Web Office等办公文档应用系统，不需借助办公软件，就可以通过ODQ 直接操作底层的流式办公文档，而不必关心底层文档的格式和平台。

为此，设计ODQ 的应用架构如图1所示。办公文档应用系统将ODQ 命令提交给ODQ 解析器，ODQ 解析器解析ODQ 命令，并通过不同流式办公文档格式的转换适配器分别调用对应格式的API来访问底层的流式办公文档。

ODQ 应用框架通过公共文档模型屏蔽了不同流式办公文档格式的差异，并通过转换适配器隐藏了不同API的调用细节，使得应用系统完全独立于底层的流式办公文档，由此，开发人员就能够更专注于上层应用的开发，而不必关心所操作的流式文档的格式和版本，从而为用户访问不同格式的流式办公文档提供统一的接口，方便用户的使用和二次开发。

图1 ODQ 应用架构

1.2 公共文档模型

每一种查询语言都基于一种特定的数据模型，如SQL针对关系型数据模型，XQuery针对层次数据模型。ODQ是针对流式办公文档的查询语言，因此，需要建立一种适合流式办公文档的数据模型，涵盖不同流式办公文档格式的常用功能点。构建公共文档模型需要遵循下面的原则：

（1）每一种流式办公文档都有自己的文档模型和格式，在充分考虑各种不同办公文档模型和格式的基础上，抽取公共语义，建立公共模型，公共文档模型不但要考虑办公文档共性功能点，还要隐藏它们之间的差异。

（2）公共文档模型要尽量的扁平化，这样才能使ODQ查询语句中的路径表达式足够的简单。文献 ［7］介绍了公共文档模型的扁平化方法。

考虑到本体是一种领域知识概念化和模型化的方法，可以实现语义信息的共享［10］。因此使用本体抽取不同格式的办公文档模型的公共语义，构建公共文档模型。

本项研究建立的公共文档模型，包括功能点集合、功能点属性集合、关系、资源和映射信息，形式化为O ＝（C，AC，R，O，AO），其中：

（1）功能点集合C：表示公共文档模型中功能点的集合，包括了所有办公文档格式中的常用概念。如document表示文档，paragraph表示段落。

（2）功能点属性集合Ac：描述公共文档模型中功能点的属性集合。

（3）关系R：表示公共文档模型中功能点之间以及功能点与属性之间的关联关系类型。

1）part－of 关系：描述一个功能点是另一个功能点的一部分，如part－of （paragraph，document）表 示paragraph是document的一部分。

2）property－of 关系：描述功能点所具有的属性，如property－of （fontName，paragraph）表示fontName （字体）是paragraph的一个属性。

（4）资源O：表示不同文档格式的功能点集合。

（5）AO描述功能点c∈C 在不同文档格式中的映射集合。用map－to 描述从公共文档模型中的功能点到具体文档格式中的功能点之间的映射关系，具体文档格式在资源O中描述。如map－to （paragraph，ooxml：p）描述了从公共文档模型中的功能点paragraph 到OOXML 文档模型中的功能点p 之间的映射，map－to （paragraph，uof：段落）描述了从公共文档模型中的功能点paragraph到UOF文档模型中的功能点 “段落”之间的映射。

整个文档公共语义抽取可以分为公共文档模型层和资源层两部分，如图2所示，资源层是不同格式的流式办公文档模型，公共文档模型层是在资源层的基础上，抽取的公共语义模型，即公共文档模型。公共文档模型中的功能点之间通过part－of 关系组成了一棵公共文档模型树；功能点与属性之间，通过property－of 关系描述；功能点或属性又通过map－to 关系，映射至资源层中不同文档模型中的功能点。

图2 公共语义抽取模型

公共文档模型中的每个功能点都拥有多个属性，表1列举了paragraph的部分属性，其中text属性描述了段落的不带式样的纯文本内容。在主流流式办公文档模型中，并没有text的概念，为了满足用户只查询文本内容的需求，添加了text属性。

表1 Paragraph的部分属性

在执行ODQ 查询命令的时候，针对的是抽象的公共文档模型，但查询的内容来自底层的文档。

1.3 ODQ 语法设计

鉴于SQL的查询语法已经深入人心，ODQ 在语法上尽量借鉴SQL的风格，并针对公共文档模型的特点做了适当的改变，使得ODQ 简单易用。下面通过扩展的EBNF范式描述ODQ 的查询命令SELECT 的语法，限于篇幅，只列出了SELECT 命令的部分定义，描述了针对document、paragraph、meta （元数据）功能点进行查询所对应的部分命令的格式。

SELECT 命令包含3个子句，说明如下：

（1）SELECT 子句：指明要查询的内容，包括功能点及其属性。需要说明的是，在该子句中出现的所有的功能点及其属性都只针对公共文档模型，与具体的底层的文档格式无关，但是，查询结果却是根据公共文档模型与底层文档格式的映射关系从底层文档获取而来。

（2）FROM 子句：FROM 关键字后面是路径表达式。路径表达式由一个或多个功能点组成，功能点之间用OF隔开，用于在文档模型中定位要查询的功能点。

（3）WHERE子句：WHERE子句中的谓词用于对结果进行过滤，多个条件之间可以用AND、OR等关键字连接。

下面几个典型示例分别用于查询功能点和属性。

例1：查询功能点的文本属性。查询功能点document的text属性，返回整个文档的文本内容。

SELECTtext FROM sample.uot

例2：查询功能点式样属性。查询功能点paragraph的fontName 和fontSize 属性，获取文档第1节中第2 个段落的字体和字号。

SELECT fontName，fontSize FROM paragraph ［2］of section ［1］of sample.docx

例3：查询功能点。查询第1节的第2段，获取功能点的所有信息，即所有属性值。

SELECT paragraph ［2］ FROM section ［2］ of sample.odf

例4：条件查询。查询字体为黑体的段落。

SELECT paragraph FROM sample.docx Where font－

Name ＝“黑体”

2 ODQ 命令的解析

ODQ 是非过程化的流式办公文档查询语言，可以嵌入到其它高级语言中。图3示意了ODQ 与应用程序的集成框架。用户通过应用程序提交ODQ 查询命令，ODQ 编译器解析ODQ 命令，并从不同格式的流式办公文档中查询结果。具体流程如图3所示。

图3 ODQ 与应用程序的集成框架

首先，应用程序将用户的ODQ 查询命令提交给ODQ编译器。词法分析器识别出命令中的符号 （token），并进行拼写检查，如果语句中的符号有拼写错误，给出提示。

语法分析器进行语法和语义检查，根据公共文档模型检查ODQ 命令的路径表达式是否正确，如果存在错误，则抛出错误信息，查询不再往下执行；如果语法和语义正确，则输出查询树。

代码生成器包含转换适配器的功能。代码生成器在遍历查询树的同时，根据公共文档模型中的map－to 关系，将针对公共文档模型的查询转换为针对具体格式文档的查询，最后生成一系列的执行计划。这些执行计划通过调用目标文档格式的API，实现对具体文档的查询。

例如用户要查询某个UOF文档第1节中第1段的文本内容，需要提交 “SELECTtext FROM paragraph ［1］OF section［1］OF test.uot”命令，生成的执行计划的部分内容如下：

上述执行计划所涉及的接口和方法都在UOF API中定义，且遵循UOF API的调用规则。如果访问OOXML 或ODF文档，则执行计划需要调用OOXML API或ODF API中定义的接口和方法。由此可以看出，代码生成器可以根据要查询的文档格式，生成相应的执行计划。

运行时系统负责执行计划，从目标文档中读取用户查询的内容，并将结果返回给应用程序。

从上面的流程可以看出，ODQ 编译器屏蔽了底层文档格式的差异以及不同文档格式API的操作细节，从而为用户提供统一的查询接口。

3 实验结果与分析

依据上面提出的理论，本文基于ANTRL 语法分析工具实现了一个原型系统，该原型系统接收用户输入的ODQ命令，并返回查询结果。

图4和图5示意了采用同一条命令分别从OOXML 文档和UOF文档中查询第2段的文本内容的实验结果。

图4 从OOXML文档中查询第2段的文本内容

从上面的结果可以看出，ODQ 可以使用相同的命令访问不同格式的文档，从而屏蔽了文档格式和版本之间的差异，为用户访问不同格式的文档提供了统一的接口。

另外，由于语法类似于SQL，ODQ 命令简单易用，与直接调用API相比，使用ODQ 可以使代码更加精简。下面分别采用ODQ、OOXML API和UOF API这3种方式，获取文档的前两个段落的文本内容，表2列举了这3种方式的代码。由此可以看出，与通过调用API访问文档的方式相比，完成同样的功能，ODQ 命令更加精简。

图5 从UOF文档中查询第2段的文本内容

表2 3种方式获取文档的前两个段落文本内容的代码比较

为了进一步比较，下面选取有代表性的13个针对元数据、段落、节和文字表的常用查询，并分别通过调用OOXML API、UOF API和ODQ 命令来实现，表3列举了分别采用3种方式所需的代码量，由此可以看出，ODQ 命令可以精简代码，降低二次开发的难度。

4 结束语

本文针对流式办公文档的格式和版本众多、平台依赖、使用API访问比较复杂的问题，提出了针对流式办公文档的查询语言ODQ。ODQ 通过本体构建公共文档模型，屏蔽不同文档格式和版本之间的差异，并为用户查询不同格式的文档提供统一的接口。实验结果证明ODQ 的命令简单易用，独立于平台和其它高级语言，降低了用户二次开发的难度，容易与各种应用集成，从而实现办公应用和数据处理的分离。

表3 使用OOXML API、UOF API和ODQ 的代码量比较

ODQ 可以与Web Service集成，实现网络办公文档的远程访问，为云计算和网络化办公提供基础，为针对 “大数据”中半结构化文档的查询提供一种解决思路。

目前，ODQ 的查询 （SELECT）功能较为完善，但部分查询命令的效率还有待提高，增 （INSERT）、删 （DELETE）、改 （UPDATE）功能还有待完善，这是后续的研究内容。

［1］ISO／IEC 29500：2008，Information technology－office open XML file formats［S］.

［2］ISO／IEC 26300：2006，Information technology－open document format for office applications（OpenDocument）v1.0［S］.

［3］GB／T 20916－2007，Specification for the Chinese office file format［S］（in Chinese）.［GB／T 20916－2007，中文办公软件文档格式规范 ［S］.］

［4］LI Xiaoqing，LIAO Husheng，ZHANG Xiaobo.Survey of XQuery implementation ［J］.Computer Science，2012，39（3）：9－18 （in Chinese）.［李小青，廖湖声，张晓博.XQuery实现技术研究综述 ［J］.计算机科学，2012，39 （3）：9－18.］

［5］SUN Qingguo，ZHU Wei，LIU Huajun，et al.Data integration of open document format on XQuery ［J］.Computer Sys－tems Applications，2008 （7）：32－34 （in Chinese）. ［孙清国，朱玮，刘华军，等.基于XQuery 的ODF 文档的数据集成［J］.计算机系统应用，2008 （7）：32－34.］

［6］TANG Yan，TIAN Ying’ai，LI Ning，et al.Analysis of methods to access XML－based fluid office documents ［J］.Computer Engineering ＆ Design，2014，35 （4）：1458－1464（in Chinese）.［唐燕，田英爱，李宁，等.几种基于XML 的流式文档访问方式分析 ［J］.计算机工程与设计，2014，35（4）：1458－1464.］

［7］LING Feng，LIU Xuhong，TIAN Ying’ai.Flatten design of open document query ［C］／／The International Conference on Cyberspace Technology，2013.

［8］LI Ning，LIANG Qi，SHI Yunmei.The function of format information in document understanding ［J］.Journal of Beijing Information Science and Technology University，2012，27（6）：1－7 （in Chinese）.［李宁，梁琦，施运梅.格式信息在文档理解中的作用 ［J］.北京信息科技大学学报 （自然科学版），2012，27 （6）：1－7.］

［9］Claudio Carpineto，Giovanni Romano.A survey of automatic query expansion in information retrieval［J］.ACM Computing Surveys，2012，44 （1）：1－50.

［10］YUAN Liu，LI Zhanhuai，CHEN Shiliang.Ontology－based annotation for deep web data［J］.Journal of Software，2008，19 （2）：237－245 （in Chinese）. ［袁 柳，李 战 怀，陈 世 亮.基于本体的Deep Web 数据标注 ［J］.软件学报，2008，19（2）：237－245.］