CN101287007A - Xml文档管理方法、系统及xml文档管理服务器 - Google Patents

Abstract

本发明公开一种XML文档管理方法，包括：当预先存储的XML文档发生改变时，通过通知消息将所述XML文档的变化信息发送给订阅过所述XML文档的客户端；所述变化信息包括变化之前和变化之后的信息。此外，本发明还公开一种XML文档管理系统及XML文档管理服务器，能够减轻客户端多文档管理的负担。

Description

XML文档管理方法、系统及XML文档管理服务器

技术领域

本发明涉及通信技术领域，尤其涉及一种XML文档管理方法、系统及XML文档管理服务器。

背景技术

XCAP(XML Configuration Access Protocol，XML配置访问协议)Diff(Different)是用来描述XML(Extensible Markup Language，可扩展标记语言)文档如何变化的协议。目前主要应用在解决多个客户端，例如XCAP Client或SIP User Agent或PRESENCE SERVER，操作服务端的一个XML文档时引起的客户端多份文档副本内容不一致的问题。通常情况下，客户端会保存一份服务端的XML文档在本地内存中，以便重复使用。如果另一个客户端修改了此XML文档，则会导致其它客户端保存的文档过期。为此，客户端可以使用SIP(Session Initiation Protocol，会话初始协议)，向服务端订阅文档的变化通知。当文档变化后，服务端通知文档订阅者客户端，通知承载的内容为XCAP Diff数据；客户端再根据XCAP Diff据所描述的内容，重建本地保存文档。

在现有技术中，XCAP Diff议要求客户端本地有对应文档的副本保留，XCAP Diff协议信息用于帮助其重建本地副本文档。其XCAP Diffschema定义如图1所示：XCAP Diff协议信息中change-log/replace给出XPATH与替换之后的文档节点的内容；XCAP Diff协议信息中change-log/remove给出删除的节点的XPATH。其中，XPATH是一种能够在XML文档中寻找信息的语言，通过XML文档中的元素和属性来进行导航。

在实现本发明的过程中，发明人经过研究发现，现有技术中的XCAP Diff协议只描述了文档是如何变化的，而没有描述变化的具体内容是什么。即，XCAP Diff信息中change-log/replace只给出了XPATH与替换之后的文档节点的内容，没有给出替换之前的文档节点的内容，对于替换属性，替换名字空间，替换注释也存在这样的问题；change-log/remove只给出了删除的节点的XPATH，并没有给出被删除的节点内容，对于删除属性，删除名字空间，删除注释同样也没有给出被删除的内容。

此外，XCAP Diff协议要求客户端本地有对应文档的副本保留，而在实际应用中，很多业务无须在本地持有所依赖文档的一份拷贝。例如，当前IMS域一些文档管理使用应用中，很多业务之间的文档是互相依赖，业务之间只关注所依赖文档中某些节点的具体内容变化，而无须在本地持有所依赖文档的一份拷贝。如果持有文档副本，当文档数量较多时，对这些文档内存缓存(或物理存储)，会造成存储空间的浪费；另外，要求客户端本地有对应文档的副本保留，也增加了对文档索引的查找时间；还限制了XCAP Diff协议在一些内存或物理存储空间比较小的嵌入式设备中的应用。如果没有持有文档副本，仅根据现有的XCAP Diff协议描述的信息将无法知道文档确切的变化内容，客户端无法知道被替换内容具体是什么。

发明内容

本发明实施例提供一种XML文档管理方法、系统及XML文档管理服务器，能够减轻客户端多文档管理的负担。

本发明实施例提供以下技术方案：

本发明实施例提供一种XML文档管理方法，包括：

当预先存储的XML文档发生改变时，通过通知消息将所述XML文档的变化信息发送给订阅过所述XML文档的客户端；所述变化信息包括变化之前和变化之后的信息。

本发明实施例还提供一种XML文档管理服务器，包括：

存储单元，用于存储XML文档；

接收单元，用于接收客户端的订阅请求；

通知单元，用于当所述存储单元预先存储的XML文档发生改变时，通过通知消息将所述XML文档的变化信息发送给所述客户端；所述变化信息包括变化之前和变化之后的信息。

此外，本发明实施例还提供一种XML文档管理系统，包括：XML文档管理服务器和客户端，其中：

所述XML文档管理服务器，用于接收所述客户端的订阅请求，并当存储的XML文档发生改变时，通过通知消息将所述XML文档的变化信息发送给所述客户端；所述变化信息包括变化之前和变化之后的信息；

所述客户端，用于发送订阅请求，接收所述XML文档管理服务器发送的通知消息。

本发明实施例在XCAP Diff协议的change-log/replace中给出替换信息的XPATH与替换之前和之后的文档信息内容；在XCAP Diff协议的change-log/remove中给出删除信息的XPATH与被删除的信息内容。通过对XCAP Diff协议进行扩展后，对于XCAP Diff应用在一些只关注文档变化内容的业务中、或者一些内存或物理存储空间比较小的嵌入式设备中，本地客户端无须持有所依赖文档的一份拷贝，而只需要通过业务之间的消息传递就能够达到业务的目的，从而减轻了客户端多文档管理的负担，提升了客户端的性能。

附图说明

图1是现有技术XCAP Diffschema定义示意图；

图2是本发明实施例XML文档管理方法流程图；

图3是本发明实施例XCAP Diff schema定义示意图；

图4是本发明实施例应用示例流程图；

图5是本发明实施例XML文档管理装置结构示意图；

图6是本发明实施例XML文档管理系统结构示意图。

具体实施方式

本发明实施例提供一种XML文档管理方法、装置、系统及XML文档管理服务器，能够减轻客户端多文档管理的负担。

如图2所示，为一个本发明实施例提供的XML文档管理方法流程图，包括以下步骤：

步骤201、存储XML文档；

步骤202、接收客户端的订阅请求；

步骤203、当所述XML文档发生改变时，通过通知消息将所述XML文档的变化信息发送给所述客户端；所述变化信息包括变化之前和变化之后的信息。

其中，步骤203中所述XML文档发生改变具体可以包括：所述XML文档的信息被替换，及所述XML文档的信息被删除，下面分别具体说明。

另一个本发明实施例提供一种XML文档管理方法，包括以下步骤：

步骤210、存储XML文档；

步骤220、接收客户端的订阅请求；

步骤230、当所述XML文档的信息被替换时，通过通知消息将所述XML文档的被替换前的信息和替换后的信息发送给所述客户端。

其中，所述信息包括节点、和/或属性、和/或名字空间、和/或注释。下面，以XML文档中的一个节点被替换为例，结合图3和图4进行详细说明。

如图3所示，为本发明实施例的XCAP Diff schema定义示意图。其针对规范中<replace>操作进行扩展：对于<replace>，本发明实施例可以包括两个子节点分别描述被替换和替换后的内容，例如<before>和<after>。<before>用于描述被替换的内容，<after>用于描述替换之后的内容。<before>的个数范围为[0，1]，而<after>的个数为1，即允许<before>不存在。需要说明的是，子节点的名称不限于<before>与<after>，只要<replace>操作扩展能够体现被替换的内容，也能体现替换之后的内容，则都属于本发明实施例的保护范围。

如图4所示，为本发明实施例的应用示例流程图。在本发明实施例中，以黑名单业务为例，黑名单中有用户A、B、C、D，用户B订阅用户A的presence信息，假如用户A的黑名单中包含用户C和用户D，后来将用户C替换成用户B，该实施例包括如下步骤：

401、用户B向呈现服务器(PRESENCE SERVER)发送订阅用户A的presence信息的订阅(SUBSCRIBE)消息；

402、PRESENCE SERVER向用户B返回202应答，表示已经接受请求；

403、PRESENCE SERVER向共享XML文档管理服务器(SHEARDXDMS)发送SUBSCRIBE消息，查询用户A的黑名单信息；

404、SHEARD XDMS向PRESENCE SERVER发送200应答；

405、SHEARD XDMS向PRESENCE SERVER发送通知(NOTIFY)消息，该NOTIFY消息携带用户A的黑名单信息；

406、PRESENCE SERVER向SHEARD XDMS发送200应答；

407、PRESENCE SERVER检查用户B是否在用户A的黑名单中，本实施例中用户A的黑名单中包含用户C和用户D，不包含用户B，因此PRESENCE SERVER向用户B发送NOTIFY消息，该NOTIFY消息携带用户A的presence信息；

408、用户B向PRESENCE SERVER返回200应答；

409、当用户A的黑名单中的用户C替换成用户B时，SHEARD XDMS向PRESENCE SERVER发送NOTIFY消息，该NOTIFY消息携带黑名单中被替换之前及之后的部分。

410、PRESENCE SERVER向SHEARD XDMS发送200应答；

411、由于现在用户B在用户A的黑名单中，PRESENCE SERVER向用户B发送NOTIFY消息，结束用户B对用户A的订阅关系，原因是拒绝(rejected)；

412、用户B向PRESENCE SERVER返回200应答。

下面对上述流程中几个主要信令举例说明：

假如用户A的uri(Unform Resource Identifier，统一资源标识符)是sip:imsuser5101@seetest.com，用户B的uri是sip:imsuser5102@seetest.com，用户C的uri是sip:imsuser5103@seetest.com，用户D的uri是sip:imsuser5104@seetest.com，则

在401中，sip:imsuser5102@seetest.com发送订阅sip:imsuser5101@seetest.com的presence信息的订阅消息，信令示例如表1所示：

表1

SUBSCRIBE sip:imsuser5101@seetest.com SIP/2.0accept:application/xcap-diff+xml，application/resource-lists+xmlallow:ACK，BYE，CANCEL，INFO，INVITE，MESSAGE，NOTIFY，OPTIONS，PRACK，UPDATEcall-id:2584556569@10.70.110.99

content-length:0cseq:1SUBSCRIBEevent:ua-profile；profile-type＝″application″；auid＝″resource-lists″；Vendor＝″vendorl″；Model＝″1″；Version＝″1.0″；document＝″/resource-lists/users/sip:usertest@ims.com/list.xml″expires:7200max-forwards:70p-asserted-identity:<sip:imsuser5102@seetest.com>privacy:nonevia:SIP/2.0/UDP 10.70.110.99:5061；branch＝z9hG4bK713970972；Role＝1contact:<sip:10.70.110.99:5061；comp＝sigcomp>from:<sip:imsuser5102@seetest.com>；tag＝2607757021to:<sip:imsuser5101@seetest.com>route:<sip:10.71.96.34:5060；lr>record-route:<sip:10.70.110.99:5061；lr>

在405中，SHARED XDMS向PRESENCE SERVER发送NOTIFY消息的信令示例如表2所示，SHARED XDMS通知PRESENCE SERVER用户sip:imsuser5102@seetest.com的黑名单信息。本例中，用户sip:imsuser5103@seetest.com和用户sip:imsuser5104@seetest.com在用户sip:imsuser5101@seetest.com的黑名单中(见表2中的下划线部分)。

表2

NOTIFY sip:10.70.110.99:5061；comp＝sigcomp SIP/SIP/2.0max-forwards:70event:ua-profilecontent-length:546content-type:application/resource-lists+xmlsubscription-state:active；expires＝7200to:<sip:imsuser5102@seetest.com>；tag＝260775702

from:<sip:imsuser5101@seetest.com>；tag＝cf8b47b4contact:<sip:10.71.96.34:15060><？xml version＝″1.0″encoding＝″UTF-8″？><rls-services                              xmlns＝″urn:ietf:arams:xml:ns:rls-services″xmlns:rl＝″urn:ietf:params:xml:ns:resource-lists″xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″><service uri＝″sip:marketing@example.com″><list name＝″marketing″><rl:entry>sip:imsuser5103@seetest.com</entry> <rl:entry>sip:imsuser5104@seetest.com</entrv></list><packages><package>presence</package></packages></service></rls-services>

在409中，SHARED XDMS向PRESENCE SERVER发送NOTIFY消息，通知PRESENCE SERVER用户sip:imsuser5101@seetest.com的黑名单中被替换的部分，信令示例如表3所示：

表3

NOTIFY sip:10.70.110.99:5061；comp＝sigcomp SIP/SIP/2.0max-forwards:70event:ua-profilecontent-length:506content-tyPe:application/resource-lists+xmlsubscription-state:active；expires＝7162to:<sip:imsuser5102@seetest.com>；tag＝2607757021

from:<sip:imsuser5101@seetest.com>；tag＝cf8b47b4contact:<sip:10.71.96.34:15060><？xml version＝″1.0″encoding＝″UTF-8″？><document            xmlns:xs＝″http://www.w3.org/2001/XMLSchema″xmlns＝″urn:ietf:params:xml:ns:xcap-diff″xmlns:rl＝″um:ietf:params:xml:ns:resource-lists″><change-log><replace sel＝″/resource-lists/users/sip:usertest@ims.com/list.xml/～/resource-lists/list[1]/entry[1]  ″>  <before><rl:entry>sip:imsuser5103@seetest.com</entry></before><！-被 替换的内容--> <after><rl:entry>sip:imsuser5102@seetest.com</entry></after> </replace></change-log></document>

其中，用户sip:imsuser5101@seetest.com的黑名单中原来的用户sip:imsuser5103@seetest.com替换为用户sip:imsuser5102@seetest.com。如表3所示，本发明实施例中的NOTIFY消息中携带了被替换的用户sip:imsuser5103@seetest.com和替换后的用户sip:imsuser5102@seetest.com(见表3中的下划线部分)，所以作为客户端的PRESENCE SERVER无需缓存黑名单文档。需要说明的是，所述RESENCE SERVER相对于作为服务端的SHARED XDMS而言是客户端，对于RESENCE SERVER而言，UE是客户端，即对于服务端SHARED XDMS而言，RESENCE SERVER和UE都是客户端，故对于PRESENCE SERVER所体现出来的有益效果对于UE而言也同样成立。

上述实施例是以SIP为例进行的说明，但是本发明实施例并不局限于SIP，其他协议的实现方式与之类似，此处不再赘述。

现有技术NOTIFY消息中只有变化之后的内容，因此客户端需要缓存黑名单文档，并在收到NOTIFY消息之后，通过查找缓存的黑名单文档才能获知变化之前的内容。而本发明实施例NOTIFY消息中既有变化之前的内容，也有变化之后的内容，因此，客户端无需缓存黑名单文档。本发明实施例对XCAP Diff扩展后，对于XCAP Diff应用在一些只关注文档变化内容的业务中，或者一些内存或物理存储空间比较小的嵌入式设备中，本地客户端无须持有所依赖文档的一份拷贝，而只需要通过业务之间的消息传递就能够达到业务的目的，从而减轻了客户端多文档管理的负担，提升了客户端的性能，客户端也不再需要根据NodeSelector遍历文档查询修改的节点。

对于属性、名字空间、或注释等信息的替换过程与节点的替换类似，此处不再赘述。

本发明实施例提供了一种XML文档管理方法，包括以下步骤：

步骤410、存储XML文档；

步骤420、接收客户端的订阅请求；

步骤430、当所述XML文档的信息被删除时，通过通知消息将所述XML文档的被删除的信息发送给所述客户端。

其中，所述信息包括节点、和/或属性、和/或名字空间、和/或注释。下面，以XML文档中的一个节点被删除为例，结合图3和图4进行详细说明。

请再次参照图3，其针对规范中<remove>操作进行扩展：对于<remove>，本发明实施例可以包括已经被删除的元素的内容。需要说明的是，不管是在<remove>节点下扩展其他的元素来表明删除的内容，还是通过其他方式，只要<remove>操作扩展能够体现被删除的内容，则都属于本发明实施例的保护范围。

请再次参照图4，为另一个本发明实施例提供的应用示例，以群组业务为例，在群组业务中，有用户A、B、C，用户C订阅用户A的群组信息，假如用户A的群组信息中有用户A和用户B两个成员，后来用户B退出该群组，则具体流程如下：

401’、用户C向PRESENCE SERVER发送订阅用户A的群组信息的SUBSCRIBE消息；

402’、PRESENCE SERVER向用户C发送202应答，表示已经接受；

403’、PRESENCE SERVER向SHEARD XDMS发送订阅用户A的群组信息的SUBSCRIBE消息，向SHEARD XDMS查询用户A的群组信息；

404’、SHEARD XDMS向PRESENCE SERVER返回200应答；

405’、SHEARD XDMS向PRESENCE SERVER发送NOTIFY消息，该NOTIFY消息携带用户A的群组信息；

406’、PRESENCE SERVER向SHEARD XDMS返回200应答；

407’、PRESENCE SERVER向用户C发送NOTIFY消息，该NOTIFY消息携带用户A的群组信息；

408’、用户C向PRESENCE SERVER返回200应答；

409’、当用户B退出群组后，SHEARD XDMS向PRESENCE SERVER发送NOTIFY消息，该NOTIFY消息携带该群组信息中删除的部分；

410’、PRESENCE SERVER向SHEARD XDMS发送200应答；

411’、PRESENCE SERVER向用户C发送NOTIFY消息，该NOTIFY消息携带该群组信息中删除的部分；

412’、用户C向PRESENCE SERVER返回200应答。

下面对上述流程中几个主要信令举例说明：

假如用户A的uri是sip:pswat001@seetest.com，用户B的uri是sip:pspre001@seetest.com，则

在401’中，用户C订阅用户sip:pswat001@seetest.com的群组信息的信令示例如表4所示：

表4

SUBSCRIBE sip:pswat001@seetest.com；transport＝udp SIP/2.0Via:SIP/2.0/UDP 10.71.130.167:5060；branch＝z9hG4bK911e802ee8b9507f16fb4d1feRoute:<sip:orig@10.70.110.108:10708；lr>Call-ID:3470dd820cfc8c8b8983d125699ab727@10.71.130.167

From:<sip:10.71.130.167:5060>；tag＝0cfc8c8bTo:<sip:pswat001@seetest.com；transport＝udp>CSeq:1SUBSCRIBEP-Asserted-Identity:<sip:10.71.130.167:5060>Event:ua-profile；profile-type＝″application″；auid＝″public-group″；Vendor＝″vendorl″；Model＝″1″；Version＝″1.0″；document＝″http://10.70.110.108/services/public-group/users/sip:pswat001@seetest.com/sip:pswat001_group@gp0001.seetest.com.xml/～～/public-group/list％5b@uri＝％22sip:pswat001_group@gp0001.seetest.com％22％5d″Expires:7200Accept:application/public-group+xml，application/xcap-diff+xmlP-Charging-Vector:icid-value＝″10.71.130.167.5060:5FD5C18D-0890-DD44-AE7B-FB2557EC2F30″；orig-ioi＝huawei.comP-Charging-Function-Addresses:ccf＝huawei.comMax-Forwards:70Allow:UPDATE，INVITE，BYE，PRACK，INFO，OPTIONS，CANCEL，SUBSCRIBE，ACK，REFER，NOTIFY，REGISTER，PUBLISH，MESSAGEContact:<sip:10.71.130.167:5060；lr>Content-Length:0

在405’中，SHARED XDMS向PRESENCE SERVER发送NOTIFY消息的信令示例如表5所示，SHARED XDMS告诉PRESENCE SERVER该群组信息，本例中该群组信息中包含sip:pswat001@seetest.com和sip:pspre001@seetest.com两个成员(见表5中的下划线部分)。

表5

NOTIFY sip:10.71.130.167:5060SIP/2.0Call-ID:3470dd820cfc8c8b8983d125699ab727@10.71.130.167

Contact:sip:10.70.110.108:5065Content-Length:518CSeq:1NOTIFYExpires:3600From:<sip:pswat001@seetest.com>；tag＝3051580358Max-Forwards:69Record-Route:<sip:10.70.110.108:10708；lr>Route:<sip:10.71.130.167:5060；lr>To:<sip:10.71.130.167:5060>；tag＝0cfc8c8bVia:SIP/2.0/UDP 10.70.110.108:10708；branch＝z9hG4bK392572620Via:SIP/2.0/UDP 10.70.110.108:5065；branch＝z9hG4bK2205615853Subscription-State:activeEvent:ua-profileP-Charging-Function-Addresses:ccf＝CAl；ecf＝ecflP-Charging-Vector:icid-value＝pcscf.imshw.bj.chinamobile.com.3377334677.35241.14；orig-ioi＝scscf.imshw.bj.chinamobile.com；term-ioi＝scscf.imshw.sh.chinamobile.comContent-TyPe:application/public-group+xml<？xmlversion＝″1.0″encoding＝″UTF-8″？><public-group         xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″xmlns＝″com:huawei:public-group″><list name＝″Dancing″uri＝″sip:pswat001_group@gP0001.seetest.com″><entry uri＝″sip:pswat001@seetest.com″owner＝″true″> <display-name>sip:pswat001@seetest.com</display-name></entry><entry uri＝″sip:pspre001@seetest.com″owner＝″false″>

<displav-name>sip:pspre001@seetest.com</displav-name></entry></list></public-group>

在409’中，SHARED XDMS向PRESENCE SERVER发送NOTIFY消息的信令示例如表6所示：

NOTIFY sip:10.70.110.99:5061；comp＝sigcomp SIP/SIP/2.0max-forwards:70event:ua-profilecontent-length:506Content-type:application/resource-lists+xmlsubscription-state:active；expires＝7162to:<sip:imsuser5102@seetest.com>；tag＝2607757021from:<sip:imsuser5101@seetest.com>；tag＝cf8b47b4contact:<sip:10.71.96.34:15060><?xml version＝″1.0"encoding＝"UTF-8"?><document                               xmlns:xs＝"http://www.w3.org/2001/XMLSchema″xmlns＝″urn:ietf:params:xml:ns:xcap-diff″xmlns:rl＝″urn:ietf:params:xml:ns:resource-lists″><change-log><change-log><remove sel＝″http://10.70.110.108/services/public-group/users/sip:pswat001@seetest.coml/sip:pswat0 01 group@gp0001.seetest.com.xml/～～/public-group/listl@uri＝′sip:pswat001 group@gp000 l.seetest.com′l/entry[2]″>  <entry uri＝″sip:pspre001@ seerest.com″"owner＝″false″> <displav-name>sip:vspre001@seetest.com</displav-tiame>  </entry>

</remove></change-log></change-log></document>

其中，当用户sip:pspre001@seetest.com退出群组后，SHARED XDMS向PRESENCE SERVER发送NOTIFY消息，告诉PRESENCE SERVER该群组信息中删除的部分。

另外，现有技术的做法无法体现删除之前的内容，客户端必须对该群组信息进行缓存。而本发明实施例包含删除之前的内容，客户端无需对该群组信息进行缓存。本发明实施例对XCAP Diff扩展后，对于XCAP Diff应用在一些只关注文档变化内容的业务中，或者一些内存或物理存储空间比较小的嵌入式设备中，本地客户端无须持有所依赖文档的一份拷贝，而只需要通过业务之间的消息传递就能够达到业务的目的，从而减轻了客户端多文档管理的负担，提升了客户端的性能，客户端也不再需要根据NodeSelector遍历文档查询修改的节点。

对于属性、名字空间、或注释等信息的删除过程与节点的删除类似，此处不再赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以存储于一计算机可读取的存储介质中，所述的存储介质，如：ROM/RAM、磁碟、光盘等。

如图5所示，为本发明实施例六提供的一种XML文档管理装置结构示意图，包括：存储单元501、接收单元502、及通知单元503；其中：

所述存储单元501，用于存储XML文档；

所述接收单元502，用于接收客户端的订阅请求；

所述通知单元503，用于当所述存储单元501预先存储的XML文档发生改变时，通过通知消息将所述XML文档的变化信息发送给所述客户端；所述变化信息包括变化之前和变化之后的信息。

其中，所述通知单元503在所述存储单元501预先存储的XML文档的信息被替换时，通过通知消息将所述XML文档的被替换前的信息和替换后的信息发送给所述客户端；及在所述存储单元501预先存储的XML文档的信息被删除时，通过通知消息将所述XML文档的被删除的信息发送给所述客户端。所述信息包括节点、和/或属性、和/或名字空间、和/或注释。

本发明实施例七提供一种XML文档管理服务器，如图5所示，包括：存储单元501、接收单元502、及通知单元503；其中：

所述存储单元501，用于存储XML文档；

所述接收单元502，用于接收客户端的订阅请求；

所述通知单元503，用于当所述存储单元501预先存储的XML文档发生改变时，通过通知消息将所述XML文档的变化信息发送给所述客户端；所述变化信息包括变化之前和变化之后的信息。

所述通知单元503在所述存储单元501预先存储的XML文档的信息被替换时，通过通知消息将所述XML文档的被替换前的信息和替换后的信息发送给所述客户端；及在所述存储单元501预先存储的XML文档的信息被删除时，通过通知消息将所述XML文档的被删除的信息发送给所述客户端。所述信息包括节点、和/或属性、和/或名字空间、和/或注释。

如图6所示，为本发明实施例八提供一种XML文档管理系统的结构示意图，包括：XML文档管理服务器600和客户端610，其中：

所述XML文档管理服务器600，用于接收所述客户端的订阅请求，并当存储的XML文档发生改变时，通过通知消息将所述XML文档的变化信息发送给所述客户端；所述变化信息包括变化之前和变化之后的信息；

所述客户端610，用于发送订阅请求，接收所述XML文档管理服务器发送的通知消息。

其中，所述XML文档管理服务器600的具体结构请参见本发明实施例七的说明，此处不再赘述。

因此，本文提供一种XML文档管理方法、系统及XML文档管理服务器。在XCAP Diff协议的change-log/replace中给出替换信息的XPATH与替换之前和之后的文档信息内容；在XCAP Diff协议的change-log/remove中给出删除信息的XPATH与被删除的信息内容。通过对XCAP Diff协议进行扩展后，对于XCAP Diff应用在一些只关注文档变化内容的业务中、或者一些内存或物理存储空间比较小的嵌入式设备中，本地客户端无须持有所依赖文档的一份拷贝，而只需要通过业务之间的消息传递就能够达到业务的目的，从而减轻了客户端多文档管理的负担，提升了客户端的性能，客户端也不再需要根据NodeSelector遍历文档查询修改的节点。

以上对本发明所提供的一种XML文档管理方法、系统及XML文档管理服务器进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (13)

1、一种可扩展标记语言XML文档管理方法，其特征在于，包括：

当预先存储的XML文档发生改变时，通过通知消息将所述XML文档的变化信息发送给订阅过所述XML文档的客户端；所述变化信息包括变化之前和变化之后的信息。

2、根据权利要求1所述的XML文档管理方法，其特征在于，所述当预先存储的XML文档发生改变时，通过通知消息将所述XML文档的变化信息发送给订阅过所述XML文档的客户端的过程为：

当预先存储的XML文档的信息被替换时，通过通知消息将所述XML文档的被替换前的信息和替换后的信息发送给订阅过所述XML文档的客户端。

3、根据权利要求1所述的XML文档管理方法，其特征在于，所述当预先存储的XML文档发生改变时，通过通知消息将所述XML文档的变化信息发送给订阅过所述XML文档的客户端的过程为：

当预先存储的XML文档的信息被删除时，通过通知消息将所述XML文档的被删除的信息发送给订阅过所述XML文档的客户端。

4、根据权利要求2或3所述的XML文档管理方法，其特征在于，所述信息包括节点、和/或属性、和/或名字空间、和/或注释。

5、一种可扩展标记语言XML文档管理服务器，其特征在于，包括：

存储单元，用于存储XML文档；

接收单元，用于接收客户端的订阅请求；

通知单元，用于当所述存储单元预先存储的XML文档发生改变时，通过通知消息将所述XML文档的变化信息发送给所述客户端；所述变化信息包括变化之前和变化之后的信息。

6、根据权利要求5所述的XML文档管理服务器，其特征在于，所述通知单元在所述存储单元预先存储的XML文档的信息被替换时，通过通知消息将所述XML文档的被替换前的信息和替换后的信息发送给所述客户端。

7、根据权利要求5所述的XML文档管理服务器，其特征在于，所述通知单元在所述存储单元预先存储的XML文档的信息被删除时，通过通知消息将所述XML文档的被删除的信息发送给所述客户端。

8、根据权利要求6或7所述的XML文档管理服务器，其特征在于，所述信息包括节点、和/或属性、和/或名字空间、和/或注释。

9、一种可扩展标记语言XML文档管理系统，其特征在于，包括：XML文档管理服务器和客户端，其中：

所述XML文档管理服务器，用于接收所述客户端的订阅请求，并当存储的XML文档发生改变时，通过通知消息将所述XML文档的变化信息发送给所述客户端；所述变化信息包括变化之前和变化之后的信息；

所述客户端，用于发送订阅请求，接收所述XML文档管理服务器发送的通知消息。

10、根据权利要求9所述的XML文档管理系统，其特征在于，所述XML文档管理服务器还用于存储XML文档。

11、根据权利要求10所述的XML文档管理系统，其特征在于，所述XML文档管理服务器在所述存储单元预先存储的XML文档的信息被替换时，通过通知消息将所述XML文档的被替换前的信息和替换后的信息发送给所述客户端。

12、根据权利要求10所述的XML文档管理系统，其特征在于，所述XML文档管理服务器在所述存储单元预先存储的XML文档的信息被删除时，通过通知消息将所述XML文档的被删除的信息发送给所述客户端。

13、根据权利要求11或12所述的XML文档管理系统，其特征在于，所述信息包括节点、和/或属性、和/或名字空间、和/或注释。

Images