WO2009115025A1 - 一种xml文档操作方法及xdms - Google Patents

一种xml文档操作方法及xdms Download PDF

Info

Publication number
WO2009115025A1
WO2009115025A1 PCT/CN2009/070797 CN2009070797W WO2009115025A1 WO 2009115025 A1 WO2009115025 A1 WO 2009115025A1 CN 2009070797 W CN2009070797 W CN 2009070797W WO 2009115025 A1 WO2009115025 A1 WO 2009115025A1
Authority
WO
WIPO (PCT)
Prior art keywords
document
request
xml
sequence value
xml document
Prior art date
Application number
PCT/CN2009/070797
Other languages
English (en)
French (fr)
Inventor
向海
伊志权
卢剑锋
丁宁
刘斌
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2009115025A1 publication Critical patent/WO2009115025A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/83—Querying

Definitions

  • the present invention relates to the field of communication applications, and in particular, to an XML document operation method and an XDMS.
  • XCAP XML Configuration Access Protocol
  • OMA Open Mobile Alliance
  • XML Extensible Markup Language
  • These signaling include creating, modifying document or node (PUT) request signaling, deleting document or node (DELETE) request signaling, searching and synchronizing document (GET) request signaling, and performing XML file management through these operational signaling ( XDM).
  • XACP Extensible Markup Language
  • OMA Open Mobile Alliance
  • each document has a version number, and the English name is etag, which is used to describe the latest version information of the document. It is generated by the XDM server (XDMS) when creating or modifying a document or node, and returns to the terminal.
  • XDMS XDM server
  • the PUT request signaling operation is specifically as follows: After receiving the request, the XDMS first searches for the requested document by the document name. If the document is found, the etag is compared. Only if the etag is identical, it is considered to have the right to operate. Otherwise, it is considered as no right, and the response is 403 (Forbidden); if the document is not found, it is processed by the newly added document. For the node operation, the document version number is also compared first. Only if it is identical, the node path (described by the uniform resource identifier) is used to analyze whether the node exists. If there is no new node processing, the replacement node is processed.
  • the DELETE request signaling operation is specifically as follows: After receiving the request, the XDMS first searches for the requested document by the document name. If the document is found, the etag is compared. Only if the etag is identical is considered to have the right to operate. Otherwise, it is considered as no right, and the response is 403 (Forbidden). If it is not found, it returns a 404 (Not Found) response.
  • the GET request signaling operation is specifically as follows: After receiving the request, the XDMS first searches for the requested document by the document name. If you find this document, compare etag, only the etag is the same to return the document, otherwise return 403 (Forbidden) response; returns a 404 (Not Found) response if not found. If the GET request does not carry an etag, the XDMS does not perform a version check and has the right to process it by default.
  • the terminal when the terminal logs in: the terminal first obtains the xcap-directory from the server by using the GET signaling, and the monthly service returns the user-related document directory information, including the Uniform Resource Identifier (URI), etag, and the like.
  • URI Uniform Resource Identifier
  • the URI consists of the following parts: AUID+USER_URI+ Document name.
  • the documents added by one terminal need to be synchronized to other terminals, and other terminals can have this document. Otherwise, after obtaining the index information of the document from xcap-directory at the time of login, the local terminal You will find that some documents do not exist.
  • the version number is compared one by one, and the changed document is identified, including the newly added documents (the local terminal is not found, but the xcap-directory has), the modified document (the etag changes), and the deleted document ( Xcap-directory does not, but the local terminal has it).
  • the physical deletion operation is performed locally; for the modified document and the newly added document, the terminal re-initiates the GET request to acquire the document in turn.
  • the embodiment of the invention provides an XML document operation method and an XDMS. After the introduction of the document sequence value, the XDMS completes the operation of the XML document after receiving the XML operation request according to the update order of the document sequence values.
  • an embodiment of the present invention provides an XML document operation method, and the method includes:
  • the corresponding document operations are completed according to the document sequence value and the XML document operation request, and the document sequence value is a sequence value established in accordance with the XML document update order.
  • an embodiment of the present invention further provides an XDMS, where the server includes:
  • a storage module configured to store an XML document and a corresponding sequence value of the document, where the sequence value of the document is a sequence value established according to an update order of the XML document;
  • a receiving module configured to receive an XML document operation request
  • the processing module is configured to complete a corresponding document operation according to the document sequence value stored by the storage module and the XML document operation request received by the receiving module.
  • the corresponding document sequence value is established for each XML document in the XDMS according to the XML document update order, and when the XML document operation request is received, the XML document version number is not compared one by one to identify the change.
  • the document can identify all the documents after the sequence value of the XML document by directly obtaining the sequence value of the document in the operation request and can return the document to the user terminal at one time, thereby reducing the interaction process between the terminal and the XDMS. Demonstrate the user experience. DRAWINGS
  • FIG. 1 is a system diagram of an operation method of an XML document in an embodiment of the present invention
  • FIG. 2 is a schematic structural diagram of a processing module in an embodiment of the present invention.
  • FIG. 3 is a flowchart of an operation method of an XML document in an embodiment of the present invention.
  • FIG. 4 is a flowchart of a PUT request processing based on a document sequence value in an embodiment of the present invention
  • FIG. 5 is a flowchart of a DELETE request processing based on a document sequence value in an embodiment of the present invention
  • FIG. 6 is a flowchart of a synchronization (SYNC) request processing based on a document sequence value in an embodiment of the present invention.
  • the embodiment of the invention provides an XML document operation method and an XDMS. After the introduction of the document sequence value, the XDMS completes the operation of the XML document after receiving the XML operation request according to the update order of the document sequence values.
  • FIG. 1 is a system diagram of an XML document operation method in an implementation of the present invention.
  • the system includes an XDMS 10 and a User Equipment (UE) 11 , where: UE 11 is used to initiate an XML document operation request to the XDMS 10, requesting Performing related XML document operation processing, the UE 11 may be a mobile terminal, a PC client, an IMS terminal, etc.; the XDMS 10 is configured to establish a corresponding document sequence value for each XML document stored in the XDMS 10, and the sequence values of the documents are in accordance with The document update order is sorted to facilitate the user's request operation, and the XML file operation request of the UE 11 is received, and the corresponding document operation is completed according to the stored document sequence value. begging.
  • UE 11 User Equipment
  • the XDMS 10 is provided with a storage module 14, a processing module 13 and a receiving module 12, wherein: a sequence value of the storage module update order is established; the receiving module 12 is configured to receive an XML document operation request; and the processing module 13 is configured to store the data according to the storage module 14.
  • the document sequence value completes the corresponding document operation according to the XML document operation request received by the receiving module 12.
  • the types of XML document operations described herein include: adding a document, modifying a document, deleting a document, acquiring a document, synchronizing a document, adding a node/property, deleting a node/attribute, etc., where the corresponding application can be passed.
  • the processing module 13 further includes a first determining unit 201, a deleting unit 202, a generating unit 203, a synchronizing unit 205, and a second judging unit.
  • the first determining unit 201 is configured to determine whether the document sequence value in the XML document operation request and the stored document sequence value are the same;
  • the deleting unit 202 is configured to determine, by the first determining unit 201, that the document sequence value is the same and
  • the XML document operation request type is a corresponding XML document deletion operation when the document request is deleted;
  • the generating unit 203 is configured to determine, by the first determining unit 201, that the document sequence value is the same and the XML document operation request type is a modified document request or delete the document node.
  • the second determining unit 204 is configured to: Determine the synchronization required in the XML document operation request based on the document sequence value XML documents range; synchronizing unit 205 for the document to an XML document according to the XML document that require synchronization determining unit determines the range of the second synchronous operation.
  • the embodiment of the invention provides a mechanism for document version control and document synchronization based on incremental or decremented document sequence values, which is implemented by a UE, an XDMS and a document sequence generator, and the document sequence generator is a processing module in the XDMS. 13.
  • the increment or decrement of the document sequence value may be the latest time stamp, and may also be incremented or decremented.
  • the time sequence is used to describe the document sequence value to distinguish it from the etag.
  • the document sequence value is preferably generated by the same document sequence generator. This ensures that the same user's documents of the same user can identify the latest generated or changed documents by the size of the sequence value.
  • the business identifier here described by AUID
  • Concepts including but not limited to OMA-defined services, such as resource-lists (grouping), org.openmobilealliance.user-profile (personal information), org.openmobilealliance.groups (group), etc., can also be custom services, such as Contact-profile (contact).
  • the document sequence generator is a document sequence value generation module.
  • the database system in the XDMS is the document sequence generator; when the time series is used as the document sequence value, the operation in the XDMS
  • the system's clock sequence is the document sequence generator.
  • Documents of the same business of the same user generally generate document sequence values by the same document sequence generator, which can avoid confusion in document change recognition. Documents of different users and different businesses use different document sequence generators to generate document sequence values, as long as it does not affect the document change relationship identification of the same user, it is also allowed.
  • FIG. 3 shows a flow chart of the XML document operation method in the embodiment of the present invention, and the steps are as follows:
  • Step S301 Receive an XML document operation request.
  • the corresponding document sequence values are created in the XDMS for the stored XML documents in the document update order, and the document sequence values are stored, and the document sequence values are established for the stored XML documents mainly according to the time series or the updated sequence of the data sequences.
  • the XML document operation request type includes adding a document request, modifying a document request, deleting a document request, adding a node/attribute request, deleting a node/attribute request, and synchronizing a document request, and the like, and is not limited to the several request operations, and the present invention is implemented.
  • the main PUT operation, DELETE operation and SYNC operation are implemented.
  • Step S302 Completing the requested document operation according to the document sequence value and the XML document operation request, the document sequence value is a sequence value established according to the XML document update order.
  • the XML document operation request generates a corresponding document sequence value for the newly added XML document according to the document sequence value update order when adding a document request or adding a document node/attribute request. It should be noted that the implementation of the method in the embodiment of the present invention is mainly implemented by using a PUT command.
  • the XML document operation request type includes: modifying a document request, deleting a document request, deleting a document node/attribute request, replacing a document node/attribute, including a document sequence value in the XML document operation request; determining the XML document operation request Whether the document sequence value and the stored document sequence value are Similarly; if the document sequence value in the XML document operation request is the same as the stored document sequence value, the XML document operation is completed according to the document sequence value.
  • the XML document operation request type is to modify a document request, delete a document node/attribute request, and replace a document node/attribute
  • the XML request type is to delete a document request
  • the XML document to be deleted is deleted according to the document sequence value. For a document that has been deleted, it cannot be obtained by the synchronization method in the embodiment of the present invention, but the Xcap-Directory can be obtained, and then the document is determined to exist. If the directory returned by the server does not exist, the document is deleted, and the terminal can be Perform a local delete.
  • the XML document operation request When the XML document operation request is a synchronous document request, the XML document operation request includes a document sequence value; and the XML document range that needs to be synchronized in the XML document operation request is determined according to the document sequence value; After the scope of the XML document, document synchronization is performed on the XML documents that need to be synchronized.
  • the XML document to be synchronized ranges from all updated XML documents based on document sequence values or all XML documents satisfying the range of values of a given document sequence value in the synchronization request.
  • the XML document synchronization operation in the embodiment of the present invention is completed by the synchronous signaling SYNC command, and the synchronization signaling includes the document content, the document name, the document sequence value, and the service identifier that need to be synchronized.
  • Step S401 The UE initiates a PUT request to the XDMX.
  • Step S402 If the document exists, compare the document sequence value, if the document sequence value is different, proceed to step S403a, if the document sequence value is the same, proceed to step S403;
  • Step S403a If the document sequence value is different, return 403 (Forbidden);
  • Step S403 The XDMS applies a document sequence value to the document sequence generator.
  • Step S404 The document sequence generator returns the requested document sequence value to the XDMS.
  • step S403 and step S404 are a process of generating a sequence value of a document, which generates a corresponding sequence value according to a certain generation rule, such as incrementing or generating a corresponding sequence value, if there is a latest document sequence value 200712031206, Then the generated next document sequence value should be 200712031207; if it is generated according to the timestamp, the document sequence value corresponding to the timestamp can be automatically generated according to the increase of the timestamp.
  • a certain generation rule such as incrementing or generating a corresponding sequence value
  • Step S405 Create or modify a document
  • each document After creating or modifying an XML document, each document can have the same document sequence value.
  • Step S406 The XDMS returns a response message to the UE.
  • the response message includes new document information and the same document sequence value of the new document information, and the document sequence value can provide a reference for the next XML document operation.
  • Step S501 The UE initiates a PUT request to the XDMS.
  • Step S502 If the document exists, compare the document sequence value, if the document sequence value is different, proceed to step S503, if the document sequence value is the same, proceed to step S504;
  • Step S503 If the document sequence value is different, returning a 403 (Forbidden) response; Step S504: deleting the document;
  • Step S505 The XDMS returns a response message to the UE.
  • the document sequence value for each document appears in the response message body.
  • the batch message value returned in the response message body returned by the batch modification document is the batch message value returned by the batch modification document:
  • each ffle corresponds to a document
  • timemark is a document sequence value according to an embodiment of the present invention.
  • the document sequence value can be returned from the document name, etag, in the following form:
  • the document can be obtained by the range of document sequence values when the terminal logs in.
  • “Incremental” or “Decremental” is the sequence generation method provided by XDMS, which also identifies the increment range in the case of incremental synchronization. For example, when a document sequence value is generated in a decreasing manner from a value, XDMS considers that the smaller the sequence value, the newer the document has recently changed. In general, document sequence values are generated incrementally, which is more customary. When synchronizing documents by document sequence value, XDMS recognizes all documents that have changed, and returns all the documents after the sequence value in one request response.
  • the document sequence value can also be used for version control. Only if the document sequence value in the request is identical (ie equal) to the document sequence value in the XDMS, it is considered to have the right to operate, otherwise it is considered as no operation, and returns 403 (Forbidden) response. . In terms of version control, the document sequence value is exactly equivalent to the role of etag.
  • FIG. 6 shows a process flow of a SYNC request processing process based on a document sequence value in an embodiment of the present invention, and the specific steps are as follows;
  • Step S601 The UE initiates a SYNC request with authentication information.
  • Step S602 Identify a document that needs to be synchronized
  • Step S603 - Return the required documents in batches or batches.
  • the documents that need to be synchronized can be returned in batches according to the number of documents.
  • Each batch of documents can contain multiple documents that need to be synchronized, and no interaction is required for each document. If there are few documents, synchronize multiple documents required at one time; if the number of documents is large, you can synchronize the required documents in multiple batches, avoiding wrapping the required documents in a large XML document.
  • the sequence reference value of the next batch of documents can be given, and the UE initiates the request for acquiring the next batch of documents according to this.
  • the document sequence value is 210 At 800 o'clock, each time 50 documents are returned, the first request can start from 21, then the next batch of sequence reference values returned for the first time is 260, then the next time the UE acquires the document, it can start from 260, and the server returns the document not found. .
  • the document synchronization request is given a starting range of the document sequence value
  • the document collection meeting the condition that the server-side document sequence value is greater than or equal to the document sequence value of the same service in the document synchronization request
  • the start value but less than the end value of the document sequence value of the same service in the document synchronization request; when the document sequence value is generated in descending order, the document set satisfying the condition refers to the document whose server sequence value is less than or equal to the same service in the document synchronization request
  • the document set satisfying the condition means that the server document sequence value is not less than the document sequence value of the same service in the document synchronization request.
  • the document set satisfying the condition means that the server document sequence value is not greater than the document sequence value of the same service in the document synchronization request.
  • Xcap-directory does not conflict with the directory of the document, in fact the terminal can still get through
  • Xcap-directory gets the document directory and knows which documents have been deleted by comparing the document list. For the synchronization of newly added and modified documents, the method of using the sequence value of the document according to the embodiment of the present invention can achieve higher efficiency.
  • Table 1 is a table diagram of SYNC signaling definitions, including request messages and response messages, where:
  • the request message includes a request line, a request message header, and a request message body, where: the request line includes the requested service, the user number that initiated the request, the requested service content, and the requested uniform resource identifier; the response message includes a response status line, a response message Header and response message body, where: The response status line includes the return code type.
  • the SYNC request consists of a Request-URI: XCAP Root + AUID + "users" + XUI.
  • the complete synchronization request line is as follows:
  • resource-lists indicates a packet service. If multiple services are synchronized, they can be replaced with special symbols, such as "00”, indicating that the synchronized service is defined in the request message body, "123324" indicates the user number that initiated the request, "sip :” means this is a sip uri, "huawei.com” is the user '123324, the home XDMS domain name.
  • SYNC request message header The format of the SYNC request message header is as follows:
  • application/sync+xml is the message body format of the SYNC request.
  • Request message body SYNC request message body format:
  • timemark is the text ⁇ : when the sequence value, the timemark of the list is '] ⁇ sheng indicates the sequence value of the document of all services Must be later than the given value, the timemark attribute in uid indicates that the document sequence value of the business corresponding to the current auid must be later than the given value, and the timemark element in the file indicates that the sequence value of the document must be equal to the given value equivalent to Etag; timemark in the above format is optional, which brings flexibility. Specifically: when the inner timemark exists, the sequence value needs to be equal to the processing.
  • name in fileType is the name of the document, you can use "*" to get all the documents; under auid, specify the specific document name and specify the document name as "*" Then, all the documents under the user auid are taken.
  • the Status-Code of the SYNC response status line is taken from the return code type defined by 0MA, such as 200 (success), 500 (internal error), 404 (not found).
  • application/sync-result+xml represents the SYNC signaling response message body format.
  • Response message body SYNC response message body format (Schema):
  • SYNC response message body namespace NameSpace
  • SYNC response message body message body is list, auid and file level, list is the root node, auid describes the service, file description document
  • the timemark attribute in the list is the reference value of all services for the next synchronization, such as the current system time.
  • the auid node: name is the auid name
  • ctype is the schema corresponding to the auid (that is, the message body format)
  • the timemark is the next synchronization reference corresponding to the service.
  • Sequence value such as the current system time; file node: name is the document name, etag is the document version number, timemark indicates the latest change time of the document (including new); when the timemark of the auid in the response message is empty, it indicates the sequence of the next synchronization of the service. Value refers to the timemark in the list
  • SYNC request message A complete SYNC request message and response message will be described below, as follows: SYNC request message:
  • the AUID of the SYNC Request-uri is "00", indicating that the user 13500000000 requests to synchronize documents of multiple services, and the service information is obtained from the request message body.
  • User 13500000000 requests synchronization of s_black and s_white under "resource-lists", and all documents under 'contact-profile".
  • the requirements for s_black and s_white are that the document sequence value is greater than or equal to "20071212121212", for '' contact-
  • the document requirement for profile is that the document sequence value is greater than or equal to "20071212123000".
  • this example returns the documents s_black, s_white, and the contact-profile in the resource-lists that meet the requirements of the document sequence value, m_12344, m_12345 in the contact-profile; the timemark value in the list is 20080101102010 as the next synchronization.
  • the benchmark of the data each service does not return a document sequence value indicating that the next synchronization reference sequence value of each service is consistent with the value returned in the list.
  • the terminal after introducing the document sequence value to the XML document, the terminal does not need to obtain the xcap-directory to compare the version number of the document one by one, identify the changed XML document, and directly tell the XDMS document the reference sequence value of the synchronization by XDMS. Identify documents that have changed since the sequence value and return to the terminal once.
  • This change simplifies the processing logic of the terminal synchronization document, and the interaction process between the terminal and the XDMS, and reduces the number of interactions between the terminal and the XDMS, thereby reducing the time for document synchronization and improving the user experience.
  • the document sequence value can be used as an alternative to the OMA etag, that is, whether the document sequence value is the same as the basis for the operation authority judgment, and after the operation authority judgment is implemented, the request for updating the document, such as adding/modifying When the operation is equal, the corresponding document sequence value can be generated for the updated document, and the document sequence value can reflect the update status of the XML document, so that the XML document operation can be better performed.
  • This may be accomplished by a computer program instructing the associated hardware, which may be stored in a computer readable storage medium, which, when executed, may include the flow of an embodiment of the methods described above.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

一种 XML文档操作方法及 XDMS 本申请要求于 2008年 3月 21日提交中国专利局、申请号为 200810026933.2、 发明名称为 "一种 XML文档操作方法及 XDMS" 的中国专利申请的优先权， 其 全部内容通过引用结合在本申请中。 技术领域
本发明涉及通信应用领域， 尤其涉及一种 XML文档操作方法及 XDMS„ 背景技术
开放移动联盟 （Open Mobile Alliance, OMA ) 定义的 XML配置访问协议 ( XML Configuration Access Protocol, XCAP )规范为用户提供了可扩展标记语 言 （ Extensible Markup Language , XML ) 文档操作信令。 这些信令包括创建、 修改文档或节点（PUT )请求信令、 删除文档或节点 （ DELETE )请求信令、 查 找和同步文档 （GET )请求信令， 通过这些操作信令完成对 XML文档管理 ( XDM )。 OMA定义的 XACP规范是通过版本号 （ etag ) 实现文档版本控制和 增量同步的。
在 OMA定义的 XCAP规范中，规定每篇文档有一个版本号，英文名为 etag, 用于描述文档最新版本信息， 由 XDM服务器（XDMS )在创建、 修改文档或节 点时生成， 并返回终端。
PUT请求信令操作具体为： XDMS收到请求后， 先按文档名查找请求的文 档。 若找到此文档则比较 etag, 只有 etag完全相同才视为有权操作， 否则视为 无权， 返回 403 ( Forbidden )响应； 若未找到文档则按新增文档处理。 对节点操 作也是先比较文档版本号， 只有完全相同才继续按节点路径 （用统一资源标识 符描述）分析节点是否存在， 若不存在按新增节点处理， 否则按替换节点处理。
DELETE请求信令操作具体为： XDMS收到请求后， 先按文档名查找请求 的文档。 若找到此文档则比较 etag, 只有 etag完全相同才视为有权操作， 否则 视为无权， 返回 403 ( Forbidden )响应； 若未找到则返回 404 ( Not Found )响应。
GET请求信令操作具体为： XDMS收到请求后， 先按文档名查找请求的文 档。 若找到此文档则比较 etag, 只有 etag完全相同才返回文档， 否则返回 403 ( Forbidden )响应； 若未找到则返回 404 ( Not Found )响应。 若 GET请求不携 带 etag, 则 XDMS不做版本检查， 按默认有权处理。
终端登陆时的同步机制：终端首先用 GET信令从服务端获取 xcap-directory, 月良务端返回用户相关文档目录信息， 包括统一资源标识符 （ Uniform Resource Identifier, URI ), etag等信息，其中 URI由以下几部分构成： AUID+USER_URI+ 文档名。
由于各人的文档要在终端緩存的， 通过某个终端添加的文档需要同步到其 它终端后， 其它终端才能有这篇文档， 否则登陆时从 xcap-directory中获得文档 的索引信息后， 本地终端会发现某些文档不存在。 终端获得 xcap-directory之后， 逐个文档比较版本号， 识别发生变更的文档， 包括新增的文档 （本地终端未找 到， 但 xcap-directory 有）、 修改的文档 （ etag 发生变化） 和删除的文档 ( xcap-directory没有， 但本地终端存有）。 对于服务端 XDMS已经删除的文档， 本地执行物理删除操作；对于已经修改的文档和新增的文档，终端重新发起 GET 请求依次获取文档。 发明内容
本发明实施例提供了一种 XML文档操作方法及 XDMS。在引入文档序列值 以后， 根据文档序列值的更新顺序， XDMS在收到 XML操作请求之后， 完成对 XML文档的操作过程。
为了解决上述技术问题， 本发明实施例提出了一种 XML文档操作方法， 该 方法包括：
接收可扩展标记语言 XML文档操作请求；
根据文档序列值和 XML文档操作请求完成相应的文档操作，所述文档序列 值为按照 XML文档更新顺序建立的序列值。
相应的， 本发明实施例还提出了一种 XDMS , 该服务器包括：
存储模块， 用于存储 XML文档及所对应的文档序列值， 所述文档序列值为 按照 XML文档更新顺序建立的序列值；
接收模块， 用于接收 XML文档操作请求；
处理模块， 用于根据所述存储模块存储的所述文档序列值和接收模块接收 的 XML文档操作请求完成相应的文档操作。 通过本发明实施例中的 XML文档操作方法，在 XDMS中按照 XML文档更 新顺序为每个 XML文档建立相应的文档序列值，在收到 XML文档操作请求时， 不用逐个比较 XML文档版本号识别变化的文档，通过直接获取的操作请求中的 文档序列值即可识别该 XML 文档序列值以后所有的文档并可以一次性返回给 用户终端， 减少了终端与 XDMS之间的交互过程， ？丈善了用户体验。 附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实施 例或现有技术描述中所需要使用的附图作简单地介绍， 显而易见地， 下面描述 中的附图仅仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付 出创造性劳动性的前提下， 还可以根据这些附图获得其他的附图。
图 1是本发明实施例中 XML文档操作方法的系统图；
图 2是本发明实施例中处理模块的结构示意图；
图 3是本发明实施例中 XML文档操作方法流程图；
图 4是本发明实施例中基于文档序列值的 PUT请求处理流程图；
图 5是本发明实施例中基于文档序列值的 DELETE请求处理流程图； 图 6是本发明实施例中基于文档序列值的同步 （SYNC )请求处理流程图。 具体实施方式
本发明实施例提供了一种 XML文档操作方法及 XDMS。在引入文档序列值 以后， 根据文档序列值的更新顺序， XDMS在收到 XML操作请求之后， 完成对 XML文档的操作过程。
下面结合附图详细说明本发明的优选实施例。
首先请参阅图 1 ,图 1示出了本发明实施中的 XML文档操作方法的系统图， 该系统包括 XDMS10和用户设备（UE ) 11 , 其中： UE11用于向 XDMS10发起 XML文档操作请求， 请求进行相关的 XML文档操作处理， 所述 UE11可以为 移动终端、 PC客户端、 IMS终端等； XDMS10用于为存储在 XDMS10中的每 一 XML文档建立相对应的文档序列值，这些文档序列值按照文档更新顺序进行 排序， 方便用户的请求操作， 通过接收 UE11的 XML文档操作请求， 并根据存 储的文档序列值对所述 UE11发起的 XML文档操作请求完成相应的文档操作请 求。
XDMS10中设有存储模块 14、 处理模块 13和接收模块 12, 其中： 存储模 文档更新顺序建立的序列值； 接收模块 12用于接收 XML文档操作请求； 处理 模块 13用于根据存储模块 14存储的文档序列值根据接收模块 12接收的 XML 文档操作请求完成相应的文档操作。 需要说明的是， 这里的所述 XML文档操作 类型包括： 添加文档、 修改文档、 删除文档、 获取文档、 同步文档、 添加节点 / 属性、 删除节点 /属性等， 这里可以在具体应用时通过相应的命令操作， 如 PUT 操作、 DELETE操作和同步（synchronize, SYNC )操作等完成， 这里也不限于 所述几种操作处理方式和命令方式。 相应的， 图 2示出了本发明实施例中处理 模块 13的结构示意图， 其中： 处理模块 13还包括了第一判断单元 201、 删除单 元 202、 生成单元 203、 同步单元 205和第二判断单元 204, 其中： 第一判断单 元 201用于判断所述 XML文档操作请求中的文档序列值和存储的文档序列值是 否相同； 删除单元 202用于第一判断单元 201判断文档序列值相同和所述 XML 文档操作请求类型为删除文档请求时， 对相应的 XML文档删除操作； 生成单元 203用于第一判断单元 201判断文档序列值相同和所述 XML文档操作请求类型 为修改文档请求或删除文档节点请求时、或所述 XML文档操作请求类型为添加 文档请求或添加文档节点 /属性请求时， 按照 XML文档更新顺序为更新或增加 的 XML文档生成相应的文档序列值；第二判断单元 204用于根据文档序列值判 断 XML文档操作请求中所需要同步的 XML文档范围； 同步单元 205用于根据 第二判断单元判断的 XML文档范围对需要同步的 XML 文档进行文档同步操 作。
本发明实施例提出了一种基于递增或递减的文档序列值进行文档版本控制 和文档同步的机制， 由 UE、 XDMS和文档序列生成器配合实现， 该文档序列生 成器即为 XDMS中的处理模块 13。 这个递增或递减的文档序列值可以是最新的 时间戳， 也可以递增或递减的数字， 本发明实施例中用 timemark来描述文档序 列值， 以区别于 etag。
同一用户同一业务的文档， 文档序列值最好由同一文档序列生成器生成， 这样可以保证同一用户同一业务的文档能通过序列值的大小识别哪些是最新生 成或变更的文档， 这里所说的业务， 是业务标识（这里用 AUID进行描述） 的 概念， 包括但不限于 OMA定义的业务， 如 resource-lists (分組）、 org.openmobilealliance.user-profile (个人信息 )、 org.openmobilealliance.groups (群 组）等， 也可以是自定义业务， 如 contact-profile (联系人）。 文档序列生成器是 一个文档序列值生成模块， 当通过数据库的序列生成方法生成文档序列值时， XDMS中的数据库系统为文档序列生成器； 当通过时间戳作为文档序列值时， XDMS中的操作系统的时钟序列为文档序列生成器。 同一用户同一业务的文档 一般由同一个文档序列生成器生成文档序列值， 可以避免在文档变更识別方面 出现混乱。 不同用户不同业务的文档采用不同的文档序列生成器生成文档序列 值， 只要不影响同一用户的文档变更先后关系识別， 也是允许的。
在请求操作 XML文档操作过程中，用户需要开通相应的请求操作业务才视 为有权操作， 否则服务器会拒绝此次请求操作， 只有在用户开通了相应的文档 操作业务时， 才为合法请求。 下面将以用户有权操作的情况下进行描述， 即用 户开通了所要请求的操作请求时，图 3示出了本发明实施例中的 XML文档操作 方法流程图， 步骤如下：
步骤 S301： 接收 XML文档操作请求；
在 XDMS中为存储的 XML文档按照文档更新顺序建立所对应的文档序列 值， 并将所述文档序列值存储， 其主要根据时间序列或数据序列的更新顺序为 存储的 XML文档建立文档序列值。
所述 XML文档操作请求类型包括添加文档请求、 修改文档请求、 删除文档 请求、 添加节点 /属性请求、 删除节点 /属性请求和同步文档请求等， 这里也不限 于这几种请求操作， 本发明实施例主要 PUT操作、 DELETE操作和 SYNC操作 等方式实现。
步骤 S302: 根据文档序列值和 XML文档操作请求完成所请求的文档操作， 所述文档序列值为按照 XML文档更新顺序建立的序列值。
所述 XML文档操作请求为添加文档请求、 或添加文档节点 /属性请求时， 根据文档序列值更新顺序为新添加的 XML文档生成相应的文档序列值。需要说 明的是， 本发明实施例中所述方法的实现主要通过 PUT命令方式实现。
所述 XML文档操作请求类型包括修改文档请求、 删除文档请求、 删除文档 节点 /属性请求、 替换文档节点 /属性时， 所述 XML文档操作请求中包括文档序 列值；判断所述 XML文档操作请求中的文档序列值和存储的文档序列值是否相 同；如果所述 XML文档操作请求中的文档序列值和存储的文档序列值相比较相 同， 则根据文档序列值完成所述 XML文档操作。 所述 XML文档操作请求类型 为修改文档请求、 删除文档节点 /属性请求和替换文档节点 /属性时， 按照 XML 请求类型为删除文档请求时， 根据文档序列值删除所需要删除的 XML文档。 对 于已经删除的文档， 无法通过本发明实施例中的同步方法获得， 但可以通过获 取 Xcap-Directory, 再判断文档是否存在， 若服务端返回的目录不存在， 则视为 文档已删除， 终端可以执行本地删除。
所述 XML文档操作请求为同步文档请求时， 所述 XML文档操作请求中包 括文档序列值； 根据文档序列值判断 XML文档操作请求中所需要同步的 XML 文档范围； 在判断完所需要进行同步的 XML文档范围后， 对需要同步的 XML 文档进行文档同步操作。所述需要同步的 XML文档范围为基于文档序列值的所 有更新的 XML文档或满足同步请求中给定文档序列值取值范围的所有 XML文 档。 当有多个基于同步请求中文档序列值的更新 XML文档需要进行同步操作， 将所述多个文档按照文档序列值一次或分批的进行同步操作。 需要说明的是， 本发明实施例中所述 XML文档同步操作是通过同步信令 SYNC命令操作完成 的， 同步信令包括需要同步的文档内容、 文档名、 文档序列值和业务标识。
下面来详细说明基于文档序列值的 PUT请求处理流程过程， 具体流程图如 图 4所示， 步骤如下：
步骤 S401： UE向 XDMX发起 PUT请求；
步骤 S402: 若文档存在， 则比较文档序列值， 如果文档序列值不同则进行 步骤 S403a, 如果文档序列值相同则进行步骤 S403；
步骤 S403a: 如果文档序列值不同， 则返回 403 ( Forbidden );
步骤 S403: XDMS向文档序列生成器申请文档序列值；
步骤 S404: 文档序列生成器向 XDMS返回申请的文档序列值；
这里需要说明的是， 步骤 S403和步骤 S404是文档序列值的生成过程， 其 按照一定的生成规则， 如递增生成相应的序列值或递减生成相应的序列值， 如 果存在最新文档序列值 200712031206 时， 那么生成的下个文档序列值应该为 200712031207; 如果时按照时间戳生成， 则自动根据时间戳的增加即可生成对 应于时间戳的文档序列值。这里可以在生成新的 XML文档时建立所对应的文档 序列值。
步骤 S405: 创建或修改文档；
在创建或修改 XML文档后， 每个文档即可有相同的文档序列值。
步骤 S406: XDMS向 UE返回应答消息。
所述应答消息中包含了新的文档信息以及新的文档信息相同的文档序列 值， 所述文档序列值可以为下次 XML文档操作时提供基准。
基于文档序列值的 DELETE请求处理流程过程的具体流程图如图 5所示， 步骤如下：
步骤 S501： UE向 XDMS发起 PUT请求；
步骤 S502: 若文档存在， 则比较文档序列值， 如果文档序列值不同则进行 步骤 S503 , 如果文档序列值相同则进行步骤 S504;
步骤 S503: 如果文档序列值不同， 则返回 403 ( Forbidden ) 响应； 步骤 S504: 删除文档；
步骤 S505: XDMS向 UE返回应答消息。
在引入了文档序列值机制后， PUT、 DELETE、 GET等 OMA XCAP信令的 应答消息头中， 应增加文档序列值信息， 用 timemark进行描述。 如 DELETE应 答消息：
HTTP/1.1 200 OK
Server:XDM-serv/OMAl .0
Date: Wed, 19 Dec 2007 06:46:19 GMT
Etag:"wMm8L"
timemark: "20071001082030"
Content-Length :0
Connection lose
如果是批量修改或获取文档， 则每篇文档的文档序列值出现在应答消息体 中。 例如批量修改文档返回的应答消息体中携带文档序列值：
<file name="index">
<result>200</result>
<err-info/> <etag>nSNji</etag>
<timemark>20071219110714</timemark>
</file> 其中，每个 ffle对应一篇文档， timemark则是本发明实施例所说的文档序列 值。
批量获取文档时， 文档序列值可以和文档名、 etag—起返回， 如采用以下形 式：
<file name="s_white" etag="iH9dv" timemark= "20071219102657">
通过文档序列值， 终端登陆时可以按文档序列值范围获取文档。 "递增" 或 "递减" 是 XDMS提供的序列生成方式， 在增量同步时也据此识别增量范围。 例如， 文档序列值自某个值起以递减方式生成时， XDMS会认为序列值越小文 档越新 最近发生变化。 通常， 文档序列值按递增方式生成， 这比较符合习 惯。 按文档序列值同步文档时， XDMS识别变更的所有文档， 在一次请求应 答中返回该序列值起以后所有的文档。
文档序列值也可用于版本控制， 只有请求中的文档序列值与 XDMS中的文 档序列值完全相同 （即相等）， 才视为有权操作， 否则视为无权操作， 返回 403 ( Forbidden ) 响应。 在版本控制方面， 文档序列值与 etag的作用完全等价。
为避免与 0MA定义的 GET信令冲突， 本发明实施例提供了一种新的同步 信令， 取名为 SYNC。 图 6示出了本发明实施例中的基于文档序列值的 SYNC 请求处理流程过程， 具体步骤如下；
步骤 S601: UE发起 SYNC请求， 带鉴权信息；
步骤 S602: 识别所需要进行同步的文档；
步骤 S603: —次或分批返回所需要的文档。
在实现同步过程中， 可以根据文档数量的多少批量返回所需要进行同步的 文档， 每批文档可以包含有多个需要进行同步的文档， 不需要每个文档进行交 互。 如果文档少， 则一次性同步所需进行的多个文档； 如果文档数量多， 则可 以分多批次同步所需要进行的文档， 避免了将所要文档都封装在一个大的 XML 文档中。 按照批量进行文档同步时， 每次返回文档时可以给出下一批文档的序 列基准值， UE根据这个发起获取下一批文档的请求。 例如， 文档序列值为 210 至 800时， 每次返回 50篇文档， 首次请求可以从 21开始， 则第一次返回的下 一批序列基准值是 260 , 则 UE下次获取文档可以从 260起 , 服务器返回未找到 文档为止。
当文档同步请求给定文档序列值起始范围时， 当文档序列值为增序生成时， 所述满足条件的文档集合指服务器端文档序列值大于等于文档同步请求中同一 业务的文档序列值起始值， 但小于文档同步请求中同一业务的文档序列值结束 值； 当文档序列值为降序生成时， 所述满足条件的文档集合指服务端文档序列 值小于等于文档同步请求中同一业务的文档序列值起始值， 但大于文档同步请 求中同一业务的文档序列值结束值。
当文档同步请求仅给定文档序列值起始值时， 当文档序列值为增序生成时， 所述满足条件的文档集合指服务端文档序列值不小于文档同步请求中同一业务 的文档序列值； 当文档序列值为降序生成时， 所述满足条件的文档集合指服务 端文档序列值不大于文档同步请求中同一业务的文档序列值。 进行增量同步时， 除非终端给定的文档序列值为系统预置的序列初试值， 否则 终端不能根据服务端返回的文档知道哪些文档已被物理删除。 需要说明的是， 本发明引入文档序列值进行文档版本识别和同步的方法与通过获取
xcap-directory得到文档目录并不冲突， 事实上终端仍然可以通过获取
xcap-directory获得文档目录， 并通过比较文档列表获知哪些文档已被删除。 对 于新增和修改过的文档同步， 采用本发明实施例所述文档序列值的方法可以获 得更高的效率。
下面将详细描述 SYNC信令格式， 表 1为 SYNC信令定义的表格图， 包括 请求消息和应答消息， 其中：
请求消息包括请求行、 请求消息头和请求消息体， 其中： 请求行包括请求 的业务、 发起请求的用户号码、 请求的业务内容、 请求的统一资源标识符； 应答消息包括应答状态行、 应答消息头和应答消息体， 其中： 应答状态行 包括返回码类型。
Figure imgf000011_0001
HTTP- Version HTTP版本， 取值 HTTP/1.1 表 1
请求行： SYNC请求由 Request-URI构成： XCAP Root + AUID + "users" + XUI。 完整的同步请求行如下：
"SYNC http://xcap.example.eom/resource-lists/users/sip:123324@huawei.com HTTP/1.1
其中， "resource-lists"表示分组业务， 如果同步多个业务可以用特殊符号替 代， 如 "00" , 表示同步的业务在请求消息体中定义， "123324" 表示发起请求 的用户号码， "sip:" 表示这是一个 sip uri, "huawei.com" 为用户 '123324， 归 属的 XDMS域名。
请求消息头： SYNC请求消息头格式如下：
Content-type: application/sync+xml
Content-Length: (… )
其中： application/sync+xml是 SYNC请求的消息体格式。
请求消息体： SYNC请求消息体格式：
<?xml version 1.0" encodings "UTF- 8 "?>
<xs: schema xmlns:xs="http://www. w3.org/2001/XMLSchema1'
xmlns="com:huawei:sync" targetNamespace= "com: huawei： sync "
elementFormDef ault= " qualified " >
<xs: element name="list">
<xs： complexTypo
<xs:sequence>
<xs: element name="auid" type="auidType"
maxOccurs="unbounded"/>
</xs:sequence>
<xs: attribute name="timemark" type="xs:string" use=" optional "/> </xs:complexType>
</xs:element>
<xs: complexType name= ' ' fileType ' ' > <xs: attribute name="name" type="xs: string" use="required"/>
<xs: attribute name="etag" type="xs: string" use="optional"/>
<xs: attribute name=" timemark" type="xs:string" use= "optional' V>
</xs: complexType>
<xs: complexType name="auidType">
<xs:sequence>
<xs: element name="file" type="fileType" maxOccurs="unbounded"/> </xs:sequence>
<xs: attribute name="name" type="xs: string" use="required"/> <xs: attribute name= "timemark 1 ' type="xs: string" use="optional"/> </xs: complexTypo
</xs:schema>
需要说明的是， 这里的 "com:huawei:sync"为 SYNC请求消息体的命名空间 ( namespace ); timemark为文^ :当序列值， list的 timemark属' ]·生表示所有业务的文 档序列值必须晚于给定的值， uid中的 timemark属性表示当前 auid对应的业务 的文档序列值必须晚于给定的值， file中的 timemark元素表示文档的序列值必须 等于给定的值 等价于 etag; 上述格式中 timemark均是可选， 这就带来了灵 活性， 具体讲： 内层的 timemark存在时， 序列值需要按等于处理， list和 auid 中的 timemark同时存在时， 取最近序列值作为基准， 如 1比 2小， 序列值为递 增方式时， 取 2, 反之取 1; 上述格式还给出了同步的范围表达方式， 越到内层 范围越小， 是个逐级收敛的过程； auidType中 name为 auid的名字， 如 name="resource-lists"; fileType中 name为文档名， 可以用 "*" 表示获取所有文 档； auid下既指定具体文档名又指定文档名为" *"时， 则取该用户 auid下的所有 文档。
应答状态行： 格式： HTTP- Version + Status-Code + Reason-Phrase 示例如下：
HTTP- Version: HTTP/1.1
Status-Code: 200
Reason-Phrase: OK
其中： SYNC应答状态行的 Status-Code取自 0MA定义的返回码类型， 如 200 (成功）、 500 (内部错误 )、 404 (未找到）。
应答消息头：
Content-Type: application/sync-result+xml
Content-Length: (... )
其中： application/sync-result+xml表示 SYNC信令应答消息体格式。 应答消息体： SYNC应答消息体格式 （ Schema ) ：
<?xml version 1.0" encodings "UTF- 8 "?>
<xs: schema xmlns:xs="http://www. w3.org/2001/XMLSchema1'
xmlns="com:huawei:sync-result" targetNamespace="com:huawei:sync-result" elementFormDef ault= " qualified " >
<xs: element name="list">
<xs： complexTypo
<xs:sequence>
<xs: element name="auid" type="auidType" maxOccurs="unbounded"/>
</xs:sequence>
<xs: attribute name="timemark" type="xs:string" use="required"/> </xs:complexType>
</xs:element>
<xs: element name="file">
<xs： complexTypo
<xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs: attribute name="name" type="xs:string" use="required"/> <xs: attribute name="etag" type="xs: string" use="required"/> <xs: attribute name="timemark" type="xs:string" use=" optional "/> </xs:complexType> </xs:element>
<xs: complexType name="auidType">
<xs:sequence>
<xs: element ref="file" maxOccurs="unbounded"/>
</xs:sequence>
<xs: attribute name="name" type="xs: string" use="required"/> <xs: attribute name="ctype" type="xs: string" use="required"/>
<xs: attribute name=" timemark" type="xs:string" use= "optional' V>
</xs: complexType>
</xs:schema>
其中： "com:huawei: sync-result"为 SYNC应答消息体命名空间（ NameSpace ); SYNC应答消息体消息体分 list、 auid和 file三级， list为根节点， auid描述业务， file描述文档； list中的 timemark属性为下次同步所有业务的基准值， 如当前系 统时间； auid节点： name为 auid名字， ctype为 auid对应的 schema (即消息体 格式） ， timemark为业务对应的下次同步基准序列值， 如当前系统时间； file节 点： name 为文档名， etag为文档版本号， timemark表示文档最新变更时间 （含 新增） ；应答消息中 auid的 timemark为空时表示业务下次同步的序列值参照 list 中的 timemark„
下面将描述一个完整的 SYNC请求消息和应答消息， 具体描述如下： SYNC请求消息：
SYNC http://www.example.com/00/users/13500000000 HTTP/1.1
X-3GPP-Intended-Identity： "13500000000"
Content-Type： application/sync+xml
Content-Length :212
<list xmlns="com:huawei:sync" timemark="20071212121212">
<auid name="resource- lists ">
<file name="s_black"/>
<file name="s_white"/>
</auid> <auid name="contact-profile" timemark= "20071212123000">
<file name="*"/>
</auid>
</list>
需要说明的是， SYNC的 Request-uri中 AUID是" 00 " ,表示用户 13500000000 要求同步多个业务的文档， 业务信息从请求消息体中获取。 用户 13500000000 请求同步 "resource-lists" 下的 s_black和 s— white, 以及' ' contact-profile"下的所 有文档，对 s_black和 s_white的要求是文档序列值大于等于 "20071212121212" , 对'' contact-profile"的文档要求是文档序列值大于等于 "20071212123000"。
SYNC应答消息：
HTTP/1.1 200 OK
Server:XDM-serv/OMAl .0
Date: Wed, 19 Dec 2007 06:15:51 GMT
Content-Length :2041
Connection： close
<list xmlns="com:huawei:sync-result" timemark="20080101102010">
<auid name="resource- lists" ctype= " application/resource-lists -i-xml " >
<file name="s_black" etag="jCNnd" timemark="20071219115838">
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name= ' ' s_black' ' >
< display-name xml:lang="zh-cn">黑名单 </display-name>
</list>
</resource-lists>
</file>
<file name="s_white" etag="iH9dv" timemark= "20071219102657">
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name= ' ' s_white ' ' >
<display-name xml:lang=''zh-cn">白名单 </display-name> <entry id="dssa" uri=" 13800000000" > <display-name
xml:lang="en-us">Stringlll</display-name>
</entry>
</list>
</resource-lists>
</file>
</auid>
<auid name="contact-profile"
ctype="application/vnd.huawei.contact-profile+xml">
<file name="m_12344" etag="PGzSU" timemark="20071219141456">
<contact-profiles xmln s = ' ' com :huawei :xml: xdm: contact-profile ' ' >
<contact-profile uri="http：〃 www.altova.com">
< display-name xml : lang= " en-u s " >String </ display-name>
<name xml:lang="en-us">
<given-name>String</given-name>
<family-name>String</family-name>
<middle-name>String</middle-name>
<name- suffix>String</name- suffix>
<name-prefix>String</name-prefix>
</name>
<mobile>String</ mobile>
</contact-profile>
</contact-profiles>
</file>
<file name="m_12345" etag="PGzSU" timemark="20071219141456">
<contact-pro files xmln s = ' ' com :huawei :xml: xdm: contact-profile ' ' >
<contact-profile
Figure imgf000017_0001
13800000001 @huawei.com">
<mobile>String4</mobile>
</contact-profile>
</contact-profiles> </file>
</auid>
</list>
需要说明的是， 此例返回 resource-lists 中符合文档序列值要求的文档 s— black、 s_white , 以及 contact-profile 中符合文档序列值要求的 m_12344、 m_12345; list中的 timemark值 20080101102010作为下次同步数据的基准， 各 业务没有返回文档序列值表示各业务的下次同步基准序列值与 list 中返回的值 一致。
综上所述， 在对 XML 文档引入文档序列值以后， 终端不必先获取 xcap-directory进行逐个比较文档版本号 , 识别发生变化的 XML文档 , 而是直接 告诉 XDMS文档同步的基准序列值，由 XDMS识别自该序列值以后发生变化的 文档并一次性返回终端。 这一变化简化了终端同步文档的处理逻辑， 以及终端 与 XDMS之间的交互过程， 也减少了终端与 XDMS之间交互的次数， 从而减少 了文档同步的时间， 改善了用户体验。 除了文档同步功能之外， 文档序列值可 以作为 OMA etag的替代方案， 即按文档序列值是否相同作为操作权限判断的依 据， 在实现了操作权限判断之后， 对于更新文档的请求， 如添加 /修改操作等时， 可以为更新文档生成相应的文档序列值， 通过所述文档序列值能够反映出 XML 文档的更新状态， 以 务器更好的进行 XML文档操作。 是可以通过计算机程序来指令相关的硬件来完成， 所述的程序可存储于一计算 机可读取存储介质中， 该程序在执行时， 可包括如上述各方法的实施例的流程。 其中， 所述的存储介质可为磁碟、 光盘、 只读存储记忆体（Read-Only Memory, ROM )或随机存储记忆体 ( Random Access Memory, RAM ) 等。
以上所揭露的仅为本发明实施例中的一些较佳实施例而已， 当然不能以此 来限定本发明之权利范围， 因此依本发明权利要求所作的等同变化， 仍属本发 明所涵盖的范围。

Claims

权 利 要 求
1、 一种 XML文档操作方法， 其特征在于， 该方法包括：
接收可扩展标记语言 XML文档操作请求；
根据文档序列值和 XML文档操作请求完成所请求的文档操作，所述文档序 列值为按照 XML文档更新顺序建立的序列值。
2、 如权利要求 1所述的 XML文档操作方法， 其特征在于， 所述方法还包 括： 为存储的 XML文档按照更新顺序建立所对应的文档序列值， 并将所述文档 序列值存储。
3、 如权利要求 2所述的 XML文档操作方法， 其特征在于， 所述为存储的 XML文档按照更新顺序建立所对应的文档序列值步骤具体为：
为存储的 XML 文档按照时间顺序或数据序列的更新顺序建立所对应的文 档序列值。
4、 如权利要求 3所述的 XML文档操作方法， 其特征在于， 所述 XML文 档操作请求类型为添加文档请求、 或修改文档请求、 或删除文档请求、 或添加 文档节点请求、 或添加文档属性请求、 或删除文档节点请求、 或删除文档属性 请求、 或查找文档请求， 或同步文档请求、 或替换文档节点、 或替换文档节点 属性。
5、 如权利要求 4所述的 XML文档操作方法， 其特征在于， 所述 XML文 档操作请求为添加文档请求、 或添加文档节点请求、 或添加文档属性请求时， 所述根据文档序列值和 XML文档操作请求完成所请求的文档操作步骤具体为： 根据 XML文档操作请求生成新的 XML文档， 并根据文档序列值更新顺序 为所述新的 XML文档生成相应的文档序列值。
6、 如权利要求 4所述的 XML文档操作方法， 其特征在于， 所述 XML文 档操作请求类型为修改文档请求、 或删除文档请求、 或删除文档节点请求、 或 删除文档属性请求、 或替换文档节点、 或替换文档节点属性时， 所述 XML文档 操作请求中包括文档序列值；
所述根据文档序列值和 XML文档操作请求完成所请求的文档操作步骤具 体为：
判断所述 XML文档操作请求中的文档序列值和存储的文档序列值是否相 同；
如果所述 XML文档操作请求中的文档序列值和存储的文档序列值相同，则 根据文档序列值完成所述 XML文档操作。
7、 如权利要求 6所述的 XML文档操作方法， 其特征在于，
所述 XML文档操作请求类型为修改文档请求、或删除文档节点、或删除文 档属性请求、 或替换文档节点、 或替换文档属性时， 所述根据文档序列值完成 所述 XML文档操作具体为： 按照 XML文档更新顺序为更新的 XML文档生成 相应的文档序列值。
8、 如权利要求 4所述的 XML文档操作方法， 其特征在于， 所述 XML文 档操作请求为同步文档请求时， 所述 XML文档操作请求中包括文档序列值； 所述根据文档序列值和 XML文档操作请求完成所请求的文档操作步骤具 体为：
根据文档序列值判断 XML文档操作请求中所需要同步的 XML文档范围； 对需要同步的 XML文档进行文档同步操作。
9、 如权利要求 8所述的 XML文档操作方法， 其特征在于，
所述需要同步的 XML文档范围为基于文档序列值的所有更新的 XML文档 或满足同步请求中给定文档序列值取值范围的所有 XML文档。
10、 如权利要求 9所述的 XML文档操作方法， 其特征在于， 所述对需要同 步的 XML文档进行文档同步操作具体为：
当有多个基于同步请求中文档序列值的更新 XML文档需要进行同步操作， 将所述多个文档按照文档序列值更新顺序一次将多个文档进行同步操作。
11、 一种 XDMS服务器， 其特征在于， 该服务器包括：
存储模块， 用于存储 XML文档及所对应的文档序列值， 所述文档序列值为 按照 XML文档更新顺序建立的序列值；
接收模块， 用于接收 XML文档操作请求；
处理模块， 用于根据所述存储模块存储的所述文档序列值和接收模块接收 的 XML文档操作请求完成相应的文档操作。
12、 如权利要求 11所述 XDMS, 其特征在于， 所述处理模块包括： 第一判断单元 ,用于判断所述 XML文档操作请求中的文档序列值和存储的 文档序列值是否相同；
删除单元，用于当所述第一判断单元判断相同和所述 XML文档操作请求类 型为删除文档请求时， 删 P 相应的 XML文档。
13、 如权利要求 12所述的 XDMS, 其特征在于， 所述处理模块还包括： 生成单元，用于当所述第一判断单元判断相同和所述 XML文档操作请求类 型为修改文档请求或删除文档节点请求时、或所述 XML文档操作请求类型为添 加文档请求或添加文档节点请求或添加文档属性请求时，按照 XML文档更新顺 序为更新或增加的 XML文档生成相应的文档序列值。
14、 如权利要求 13所述的 XDMS, 其特征在于， 所述处理模块还包括： 第二判断单元，用于根据文档序列值判断 XML文档操作请求中所需要同步 的 XML文档范围；
同步单元，用于根据第二判断单元判断的 XML文档范围对需要同步的 XML 文档进行文档同步操作。
PCT/CN2009/070797 2008-03-21 2009-03-16 一种xml文档操作方法及xdms WO2009115025A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2008100269332A CN101256572B (zh) 2008-03-21 2008-03-21 一种xml文档操作方法及xdms
CN200810026933.2 2008-03-21

Publications (1)

Publication Number Publication Date
WO2009115025A1 true WO2009115025A1 (zh) 2009-09-24

Family

ID=39891398

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/070797 WO2009115025A1 (zh) 2008-03-21 2009-03-16 一种xml文档操作方法及xdms

Country Status (2)

Country Link
CN (1) CN101256572B (zh)
WO (1) WO2009115025A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101256572B (zh) * 2008-03-21 2011-08-10 华为技术有限公司 一种xml文档操作方法及xdms
WO2011037500A1 (en) * 2009-09-22 2011-03-31 Telefonaktiebolaget Lm Ericsson (Publ) A method and arrangements for enabling modifications of xml documents
CN103780483A (zh) * 2012-10-26 2014-05-07 中兴通讯股份有限公司 一种物联网终端设备的资源信息获取方法、系统及设备
US9104717B2 (en) * 2013-01-31 2015-08-11 Futurewei Technologies, Inc. Distributed storage object delete
CN103607451B (zh) * 2013-11-18 2017-02-15 上海爱数信息技术股份有限公司 支持并发的客户端与服务器端的文档操作同步方法
CN106330579B (zh) * 2015-06-15 2020-04-28 中兴通讯股份有限公司 一种用于ptn设备的丢包统计方法及装置
CN113934452B (zh) * 2021-09-30 2022-08-09 北京五八信息技术有限公司 一种数据处理方法、装置、电子设备及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1711766A (zh) * 2002-11-14 2005-12-21 Lg电子株式会社 电子文档版本化方法和使用基于可扩展标识语言的版本号的更新文档提供方法
US20070043686A1 (en) * 2005-08-22 2007-02-22 International Business Machines Corporation Xml sub-document versioning method in xml databases using record storages
CN1987912A (zh) * 2005-12-21 2007-06-27 国际商业机器公司 为电子邮件消息的附加文档提供版本控制的方法和系统
CN101005417A (zh) * 2006-09-07 2007-07-25 天栢宽带网络科技（上海）有限公司 数据广播内容自动更新的方法和系统
US20080114795A1 (en) * 2006-11-14 2008-05-15 Microsoft Corporation On-demand incremental update of data structures using edit list
CN101256572A (zh) * 2008-03-21 2008-09-03 华为技术有限公司 一种xml文档操作方法及xdms

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1711766A (zh) * 2002-11-14 2005-12-21 Lg电子株式会社 电子文档版本化方法和使用基于可扩展标识语言的版本号的更新文档提供方法
US20070043686A1 (en) * 2005-08-22 2007-02-22 International Business Machines Corporation Xml sub-document versioning method in xml databases using record storages
CN1987912A (zh) * 2005-12-21 2007-06-27 国际商业机器公司 为电子邮件消息的附加文档提供版本控制的方法和系统
CN101005417A (zh) * 2006-09-07 2007-07-25 天栢宽带网络科技（上海）有限公司 数据广播内容自动更新的方法和系统
US20080114795A1 (en) * 2006-11-14 2008-05-15 Microsoft Corporation On-demand incremental update of data structures using edit list
CN101256572A (zh) * 2008-03-21 2008-09-03 华为技术有限公司 一种xml文档操作方法及xdms

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Fhe Externsible Markup Language(XML) Configuration Access Protocol draft-ietf-simple-xcap-12", 13 October 2006, pages: 34 - 46 *

Also Published As

Publication number Publication date
CN101256572B (zh) 2011-08-10
CN101256572A (zh) 2008-09-03

Similar Documents

Publication Publication Date Title
EP2207305B1 (en) A method and a system for address book processing
US7797010B1 (en) Systems and methods for talk group distribution
EP2327199B1 (en) System and method for access and communication between a converged network-based address book system and a user device
US7864716B1 (en) Talk group management architecture
US20090298489A1 (en) System and method for a converged network-based address book
US7738900B1 (en) Systems and methods of group distribution for latency sensitive applications
US20090187622A1 (en) Method, system and apparatus for data synchronization
US8230003B2 (en) XDM system and method for implementing XML document management function by using position description of XML document
WO2009115025A1 (zh) 一种xml文档操作方法及xdms
US20100161807A1 (en) Method and apparatus for address book updates
US20080256117A1 (en) Managing entity data in case of multiple entity identities
US20100287253A1 (en) Method, apparatus, and system for data synchronization
US20110214051A1 (en) Methods and apparatus to subscribe for change notifications in a document management system
WO2009076910A1 (zh) 一种文档管理方法、系统及相关设备
WO2015011158A1 (en) User friendly names for stored cpm conversation histories
US9237206B2 (en) Method and apparatus for updating personal information in communication system
EP2529537B1 (en) Method and application server for using a sip service from a non-sip device
KR20130082561A (ko) 연락처 정보의 구독을 초대하는 장치 및 방법
EP1862932B1 (en) Managing information in XML document management architecture
WO2009049519A1 (fr) Procédé, dispositif et système de copie de contenu
US20130091287A1 (en) System for contact subscription invitations in a cross-domain converged address book system
EP1845457A1 (en) Document management architecture
US9336261B2 (en) Method and apparatus for updating personal information in communication system
US20140019417A1 (en) Method and apparatus for managing personal information in a communication system
WO2010091564A1 (zh) 一种获取节点信息的方法、服务器以及系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09721818

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09721818

Country of ref document: EP

Kind code of ref document: A1