WO2009076910A1 - 一种文档管理方法、系统及相关设备 - Google Patents

一种文档管理方法、系统及相关设备 Download PDF

Info

Publication number
WO2009076910A1
WO2009076910A1 PCT/CN2008/073482 CN2008073482W WO2009076910A1 WO 2009076910 A1 WO2009076910 A1 WO 2009076910A1 CN 2008073482 W CN2008073482 W CN 2008073482W WO 2009076910 A1 WO2009076910 A1 WO 2009076910A1
Authority
WO
WIPO (PCT)
Prior art keywords
document management
request
batch
batch processing
processing
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/CN2008/073482
Other languages
English (en)
French (fr)
Inventor
Hai XIANG
Zhiquan Yi
Jianfeng Lu
Ning DING
Bin Liu
Gaofeng Li
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to EP08861879A priority Critical patent/EP2209264A4/en
Publication of WO2009076910A1 publication Critical patent/WO2009076910A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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

Definitions

  • XML is a set of rules that define semantic markup. The defined markup divides the document into many parts and identifies them.
  • XML-compliant documents are XML documents.
  • XML documents have the advantage of being easy to read and write, and are an ideal format for describing data and exchanging data in network applications.
  • the XML Document Management Client can use the document management request, "GET” defined in the XML Configuration Access Protocol (XCAP) in the OMA (Open MOBIE Alliance) standard. , “PUT”, “DELETE” and other methods to query, add, modify, delete, etc. the application configuration data stored in XML format on the XML Document Management Server (XDMS: XML Document Management Server).
  • XCAP XML Configuration Access Protocol
  • OMA Open MOBIE Alliance
  • the user can perform corresponding operations such as querying, adding, modifying, and deleting a single document in an XDMS or a single node in a single document through the above three request operations.
  • corresponding operations such as querying, adding, modifying, and deleting a single document in an XDMS or a single node in a single document
  • An embodiment of the present invention provides an extensible markup language document management request method, including: The user's document management batch processing request indication; generating a document management batch processing request according to the document management batch processing request indication; and transmitting the document management batch processing request to the server.
  • a corresponding extensible markup language document management method comprising: receiving a document management request; determining that the received document management request is a document management batch processing request; and obtaining corresponding document management batch processing information from the document management batch processing request According to the document management batch processing information, the corresponding document management batch processing operation is performed.
  • the embodiment of the present invention further provides an extensible markup language document management client, including: a user operation unit, configured to receive a batch processing request indication of the user; and a request generating unit, configured to generate, according to the document management batch processing request indication The document management batch processing request; the request sending unit, configured to send the document management batch processing request to the server.
  • an extensible markup language document management client including: a user operation unit, configured to receive a batch processing request indication of the user; and a request generating unit, configured to generate, according to the document management batch processing request indication The document management batch processing request; the request sending unit, configured to send the document management batch processing request to the server.
  • an extensible markup language document management server comprising: a request receiving unit, configured to receive a document management request; a request parsing unit, configured to determine the document management request as a document management batch processing request, and manage batches from the document Obtaining corresponding document management batch processing information in the processing request; the request processing unit is configured to execute the corresponding document management batch processing operation according to the document management batch processing information.
  • an extensible markup language document management system comprising a client and a server, the client comprising: a user operation unit, configured to receive a batch processing request indication of the user; and a request generating unit, configured to manage batch processing according to the document
  • the request indication generates a document management batch processing request
  • the request sending unit is configured to send the document management batch processing request to the server
  • the server includes: a request receiving unit, configured to receive a document management request; and a request parsing unit, configured to determine
  • the document management request is a document management batch processing request, and the corresponding document management batch processing information is obtained from the document management batch processing request;
  • the request processing unit is configured to execute the corresponding document according to the document management batch processing information Manage batch processing operations.
  • the client needs to perform batch processing operation indications on multiple documents or multiple nodes under a single document, and sends a batch processing request to the server through a document management, and the server determines the document management batch processing request.
  • the delay increases the operational efficiency and improves the reliability of data operations.
  • FIG. 2 is a schematic flowchart of an XML document management method according to an embodiment of the present invention
  • FIG. 3 is a schematic flowchart of a method for processing an XML document management batch addition/modification (PUTS) according to an embodiment of the present invention
  • FIG. 4 is a flow chart showing an XML document management batch query (GETS) processing method according to an embodiment of the present invention
  • FIG. 5 is a schematic flowchart of a method for processing XML document management batch deletion (DELETES) according to an embodiment of the present invention
  • FIG. 6 is a flow chart showing an XML document management batch move (MOVE) processing method according to an embodiment of the present invention
  • FIG. 7 is a schematic diagram of the composition of an XML document management system according to an embodiment of the present invention.
  • FIG. 8 is a schematic structural diagram of an XML document management client according to an embodiment of the present invention.
  • FIG. 9 is a schematic structural diagram of an XML document management server according to an embodiment of the present invention. detailed description
  • An embodiment of the present invention provides a document management request method, where a client sends a document management batch processing request for processing a plurality of documents or a plurality of nodes under a single document to a server, and the server determines that the document management batch processing request is , perform corresponding document management batch processing operations.
  • the embodiment of the invention further provides a corresponding XML document management method, an XML document management system, an XML document management client and an XML document management server. The details are described separately below.
  • 1 is a schematic flowchart of an XML document management request method according to an embodiment of the present invention, including the steps:
  • the document management batch processing request is a document management batch addition/modification request indication, or a document management batch query request indication, or a document management batch deletion request indication, or a document management batch movement request indication.
  • the document management batch addition/modification request indication means that the user needs to simultaneously add multiple documents or multiple nodes under a single document or The modified operation requirement, the XDMC can obtain the user's batch increase/modification request indication through the operation interface provided to the user.
  • the document management batch query request indication refers to an operation requirement that the user needs to simultaneously query multiple nodes under multiple documents or a single document
  • XDMC The user's bulk query request indication can be obtained through an operation interface provided to the user.
  • the document management batch deletion request indication refers to a requirement that the user needs to delete multiple nodes simultaneously under multiple documents or a single document, and the XDMC may The user's batch increase/modification request indication is obtained through an operation interface provided to the user.
  • the document management batch mobile request indication refers to a user needing to multiple documents or The operation requirement of multiple nodes under a single document to move at the same time, XDMC can obtain the user's batch movement request indication through the operation interface provided to the user.
  • the document management batch processing request is mainly composed of the following parts:
  • the request line includes: Method (method name), Request-URL, and HTTP- Version (HTTP protocol version number).
  • the standard XCAP signaling Request-URI format is: XCAP Root + AUID + "users,, + XUI + filename.
  • XCAP Root 7 http://xcap.example.eom/org.openmobilealliance.user- Profile/users/sip:zhangshan@h uawei.com/index.xml
  • XCAP Root 7 http://xcap.example.com/, AUID is org .
  • XUI openmobilealliance.user-profile
  • "users” is a constant , the following is the user letter ' ( XUI )
  • XUI is sip: user @huawei.com ( sip: indicates that XUI is tel uri , huawei.com is the XDMS home domain name), and the file name is index.xml.
  • the present invention requires a batch tag "batch” instead of a filename (which can also be tagged with other strings). If you need to operate multiple services at the same time, the AUID in the Request-URI is replaced by a specific string that does not represent any specific service, such as "00". The specific business to be operated is placed after "xs:schema," In the message body, if only one service is currently operated, the real service identifier can be stored in the Request-URI.
  • the Request-URI of the XCAP batch request line can be expressed as:
  • the format of the message body for each XCAP bulk processing request is different, and the Content-Type is different.
  • the present invention stipulates that the Content-Type of several batch requests is defined as follows:
  • PUTS application/puts+xml (corresponding to document management batch increase/modification);
  • DELETES application/deletes+xml (corresponding to document management delete query);
  • the above Content-Type can also be defined as other values, but it needs to be different from the type already defined by 0MA.
  • request message body The request message body format of each batch processing request signaling is different, which will be described later.
  • the namespace of the batch request message (NameSpace and targetNamespace ) is described at the beginning of the message body. E.g:
  • A3. Send the document management batch processing request to the server.
  • the XDMC may send the document management bulk processing request to the XDMS in a manner that sends existing other types of document management requests.
  • the XDMC receives the processing result response message of the XDMS for the document management batch processing request.
  • the processing result response message of the XDMS to the document management batch processing request corresponds to different types of document management batch processing request documents.
  • the message format for managing batch processing messages is different. The following describes the process of receiving and processing document management batch processing messages by XDMC in the description of the specific type of document management batch processing.
  • FIG. 2 it is a schematic flowchart of an XML document management method according to an embodiment of the present invention, including the steps:
  • This step can be performed by referring to the receiving method of the existing document management request.
  • the XDMS can determine its type by parsing the received document management request according to the conventions that are shared with XDMC. For example, the document management batch processing request is identified by a newly defined method name, and corresponding to various types of document management batch processing request definitions are identified by corresponding method names.
  • the XDMS first parses the message header of the document management request by identifying the Content-Type type (each type of document management batch processing request corresponds to The unique Content-Type type identifier, and the message body of the document management batch processing request is decoded according to the message body format of the Content-Type type according to the XDMS and XDMC convention, and the corresponding document management batch processing information is obtained.
  • the message body format of different types of document management batch processing requests in the embodiment of the present invention is different.
  • XDMC Corresponding to a specific type of document management batch processing request, XDMC generates a corresponding document management batch processing request based on the message body format encoding agreed with the XDMS, and at the same time, XDMC identifies the message body format type through the Content-Type type in the message header, XDMS After receiving the document management batch processing request, parsing the Content-Type type identifier in the message header, obtaining the identifier message body format type, and decoding the message body of the document management batch processing request according to the message body format corresponding to the message format type .
  • B4. Manage batch processing information according to the document, and execute a corresponding document management batch processing operation.
  • B5. Return a document management batch processing response message to the client.
  • the document management batch processing response message is assembled according to the corresponding document management batch processing operation response message format, and the document management batch processing response message is sent to the document management client.
  • Etag entity-tag Jf is not related to the same source [RFC2616] section 14.19, the same as 14.24, 14.26, 14.44
  • the response message body format for each batch signaling will be described later, depending on the request.
  • the client needs to perform batch processing operation indications on multiple documents or multiple nodes under a single document, and sends a batch processing request to the server through a document management, and the server determines the batch processing request for the document management.
  • the server determines the batch processing request for the document management.
  • the operation delay increases the operation efficiency and improves the reliability of data operation.
  • FIG. 3 it is a schematic flowchart of an XML document management batch addition/modification (PUTS) processing method according to an embodiment of the present invention, which will be described in detail below.
  • PUTS XML document management batch addition/modification
  • Step s401 The XDMC sends a document management batch addition/modification processing request to the XDMS.
  • the file management batch increase/modify processing request signaling format is as follows:
  • the PUTS signaling request line is as follows: PUTS http://xcap.example.eom/00/users/sip:XXX@huawei.corn/batch HTTP/1.1
  • batch means to add or modify documents in batches
  • "00” is an auid substitute, indicating that the specific service of the operation is defined in the message
  • XXX means the user number that initiated the request
  • sip: means this is a sip uri
  • @huawei.com is the XDMS domain name to which the user XXX belongs.
  • the PUTS signaling request message header is as follows:
  • Application/puts+xml is the message body format of the PUTS request. It can be other tags, but it must be different from other OMA definitions.
  • the PUTS request message body is defined for the batch processing characteristics of the PUTS request message
  • the PUTS request message is divided into four levels: list, auid, file, and node. It can be other contract attribute names: list is the root node, auid indicates the service to be processed, file indicates the document to be processed, and node indicates the node to be processed.
  • multiple operations can be performed on multiple services (represented by AUID), and operations of adding or modifying multiple nodes can be performed on the same document.
  • auidType name is the name of auid
  • fileType name is the document name
  • ctype is the cType type of the document
  • etag is the document version number.
  • uri attribute indicates the path of the node to be inserted or replaced in the xml document, and the uri value uses the Xpath syntax.
  • This example represents a user request to modify the document 13500012345 index.xml ims-pim (auid personal information) while modifying resource-lists (Table 1 J bad packet AUID) document friend.xml; ims-pim is a ctype "Application/ims-pim+xml" , this has another 1 J in the message body
  • the namespace of ims-pim is "com:huawei:ims-pim" , and there is another 1 J in the message body.
  • the version number etag is not specified, indicating that the default has permissions
  • Ctype 7 (7 "application/xcap-el+xml" of friend.xml , indicating that the node is modified;
  • the etag of friend.xml is "abbbbcc", which means that the server needs to be versioned. If the version number is different, the node is not allowed to be modified.
  • the node path is described by the uri attribute in the node tag.
  • step s402 the PUTS batch processing request is decoded according to the PUTS request message format, and the PUTS batch processing information is obtained.
  • the XDMS parses the header of the PUTS batch processing request, obtains the Content-Type type as application/puts+xml, and then decodes the PUTS batch processing request message body according to the corresponding PUTS message body format to obtain the PUTS batch processing information.
  • Step s403 Perform PUTS batch processing operations according to the batch processing information of the PUTS, and complete batch modification or modification of the corresponding document information.
  • Step s404 The PUTS batch processing result is encoded according to a PUTS response message format.
  • the PUTS response message consists of the following:
  • Application/puts-result+xml is the PUTS response message body format. It can be other tags, but it must be different from other OMA definitions.
  • the PUTS response message body format is as follows:
  • the PUTS response message body is defined for the batch processing characteristics of the PUTS response message and is a supplement to OMA XCAP;
  • the PUTS response message body includes list, auid, and file levels, list is the root node, auid describes the service information, file describes the document information, and may also be other agreed element names;
  • Auid node name is auid name, ctype is the schema corresponding to auid;
  • File node name is the document name, result is the return code of each document operation (refer to the definition of return code in OMA XCAP PUT signaling), etag is the new version number of the document;
  • Create a document or node success result takes 201, modify the document or node success result takes 200.
  • An example of a PUTS batch processing response message is as follows:
  • Step s405 returning a response message to the client.
  • FIG. 4 it is a schematic flowchart of an XML document management batch query (GETS) processing method according to an embodiment of the present invention, which will be described in detail below.
  • GETS XML document management batch query
  • Step s501 sending a GETS batch processing request.
  • the file management batch query processing request signaling format is as follows:
  • Request-URI HTTP URI Specifies the XCAP resource for the requested operation.
  • the GETS signaling request message header is as follows:
  • Application/gets+xml is the message body format of the GETS request. It can be other tags, but it must be different from other OMA definitions.
  • the GETS request message body is defined for the batch characteristics of the GETS request message and is a supplement to OMA XCAP;
  • the GETS request message is divided into three levels: list, auid, and file, which can be used to describe multiple documents that acquire multiple services at one time.
  • list is the root node
  • auid represents the business to be processed
  • file represents the document to be processed
  • the name in the fileType is the name of the document. It can be a wildcard. For example, if you use "*,” to get all the documents; if you specify both the specific document name and the document name "*" under auid, all the documents under the user auid are taken.
  • the above example shows that the user 13500012345 requests to get all the documents under index.xml and resource-lists under ims-pim.
  • Step s502 The GETS batch processing request is decoded according to the GETS request message format, and the GETS batch processing information is obtained.
  • the XDMS parses the header of the GETS batch processing request, obtains the Content-Type type as application/gets+xml, and then decodes the GETS batch processing request message body according to the corresponding GETS message body format to obtain the GETS batch processing information.
  • Step s503 Perform a GETS batch processing operation according to the GETS batch processing information, and complete the corresponding batch query of the document information.
  • Step s504 The result of the batch processing of the GETS is encoded according to the GETS response message format.
  • the GETS response message consists of the following:
  • HTTP version HTTP- Version: HTTP/1.1
  • Application/gets-result+xml is the GETS response message body format. It can be other tags, but it must be different from other OMA definitions.
  • the GETS response message body is defined for the batch nature of the GETS response message and is a supplement to OMA XCAP;
  • the GETS response message body is divided into three levels: list, auid, and file.
  • list is the root node.
  • auid describes the service, the file description document, and other contract names.
  • Auid node name is auid name
  • ctype is the schema corresponding to auid (that is, message body format)
  • file node name is the document name
  • etag is the document version number.
  • Step s505 returning a response message to the client.
  • FIG. 5 it is a schematic flowchart of an XML document management batch deletion (DELETES) processing method according to an embodiment of the present invention, which is described in detail below.
  • DELETES XML document management batch deletion
  • Step s601 sending a DELETES batch processing request.
  • the file management batch deletion processing request signaling format is as follows:
  • the DELETES signaling request line is as follows:
  • batch means to delete documents or nodes in batches
  • "00” is an auid substitute, indicating that the specific service of the operation is defined in the message
  • XXX means the user number that initiated the request
  • sip: means that this is a sip uri
  • @huawei.com is the XDMS domain name to which the user XXX belongs.
  • request message header The DELETES signaling request message header is as follows:
  • Application/deletes+xml is the message body format of the DELETES request. It can be other tags, but it must be different from other OMA definitions.
  • the DELETES request message body is defined for the batch nature of the DELETES request message. "com:huawei:deletes” is the namespace of the DELETES request message (NameSpace), which can be other agreed values;
  • the DELETES request message is divided into four levels: list, auid, file, and node.
  • list is the root node
  • auid is the service identifier
  • file is the deleted document
  • node is the deleted node.
  • auidType name is the name of auid
  • fileType name is the document name, and etag is the document version number
  • Node The XPATH path of the node.
  • This example indicates that the user 13500012345 requests to perform a document bulk delete operation
  • Step s602 Decode the DELETES batch processing request according to the DELETES request message format, and obtain the DELETES batch processing information.
  • XDMS parses the message header of the DELETES batch processing request, obtains the Content-Type type as application/ddetes+xml, and then decodes the DELETES batch processing request message body according to the corresponding DELETES message body format to obtain the DELETES batch processing information.
  • Step s603 according to the DELETES batch processing information, perform a DELETES batch processing operation, and complete the corresponding deletion of the document information in batches.
  • step s604 the result of the batch processing of the DELETES is encoded according to the DELETES response message format.
  • the DELETES response message consists of the following:
  • the DELETES response message has no message body, so there is no need to define a Content-Type.
  • FIG. 6 is a schematic flowchart of an XML document management batch move (MOVE) processing method according to an embodiment of the present invention, which will be described in detail below.
  • MOVE XML document management batch move
  • Step s701 sending a MOVE batch processing request.
  • the document management batch mobile processing request signaling format is as follows:
  • Request-URI HTTP URI Specifies the XCAP resource for the requested operation.
  • the MOVE signaling request line is as follows:
  • the MOVE signaling request message header is as follows: Content-Type: application/mo ve+xml
  • Application/mo ve+xml is the message body format of the MOVE request. It can be other tags, but it must be different from other OMA definitions.
  • the MOVE request message body is defined for the batch nature of the MOVE request message and is a supplement to OMA XCAP;
  • the MOVE request message body consists of a list and 1 ⁇ N node nodes, each node containing a sequence number ( seq ), a source path (in the from tag, following the XPATH syntax), and a destination path (in the to tag, following the XPATH syntax).
  • seq sequence number
  • source path in the from tag, following the XPATH syntax
  • destination path in the to tag, following the XPATH syntax
  • filename is the source document name
  • etag is the source document version number
  • filename is the destination document name, and etag is the destination document version number
  • MOVE signaling can be used to move nodes between different documents, or to move nodes within the same document.
  • This example indicates that the user 13500012345 requests to perform a node move operation between documents for the "resource-lists” service, and group the nodes named “friends" in listl.xml ( Move to the "colleague” group of the document list2.xml.
  • Step s702 The MOVE batch processing request is decoded according to the MOVE request message format, and the MOVE batch processing information is obtained.
  • the XDMS parses the message header of the MOVE batch processing request, obtains the Content-Type type as application/move+xml, and then decodes the MOVE batch processing request message body according to the corresponding MOVE message body format to obtain the MOVE batch processing information.
  • Step s703 according to the MOVE batch processing information, perform a MOVE batch processing operation, and complete the corresponding batch movement of the document information.
  • Step s704 The result of the MOVE batch processing is encoded according to the MOVE response message format.
  • the MOVE response message consists of the following:
  • Step s705 returning a response message to the client.
  • the XML document management system, the XML document management client, and the XML document management server corresponding to the above method embodiments are described in detail below.
  • FIG. 7 is a schematic diagram of a composition of an XML document management system according to an embodiment of the present invention.
  • the XML document management system can execute the XML document management request method and the XML document management method in the foregoing method embodiments.
  • the XML document management client 1 is configured to generate a document management batch processing request according to the document management batch processing request indication input by the user, and send the document management batch processing request to the server 2; and receive the document management batch from the server 2 Processing the response message, reading the status code carried in the batch processing response message, and identifying whether the message body exists according to the message header of the batch processing response message, and if yes, processing the message body format according to the corresponding batch processing
  • the message body is decoded to obtain document management batch processing result information;
  • the XML document management server 2 is configured to receive a document management request, determine the document management request as a document management batch processing request, obtain corresponding document management batch processing information from the document management batch processing request, and manage according to the document Batch processing information, performing corresponding document management batch processing operations; based on document execution batch processing operation execution result information, assembling and generating document management batch processing response message according to corresponding document management batch processing operation response message format, and reporting to the document management client 1 Send the document management batch processing response message.
  • FIG. 8 is a schematic structural diagram of an XML document management client according to an embodiment of the present invention.
  • the client user operation unit 11 is configured to receive a batch processing request indication of a user.
  • a request generating unit 12 configured to generate a document management according to the document management batch processing request indication Batch processing requests;
  • a request sending unit 13 is configured to send the document management batch processing request to the server;
  • a response message receiving unit 14 is configured to receive a batch processing response message from the server; and
  • a response message processing unit 15 is configured to read the batch processing Responding to the status code carried in the message, and identifying whether the message body exists according to the message header of the batch processing response message, and if yes, decoding the message body according to the corresponding batch processing response message body format, and obtaining the document management batch processing result information.
  • FIG. 9 is a schematic structural diagram of an XML document management server according to an embodiment of the present invention.
  • the server is mainly used to execute the XML document management method in the foregoing method embodiment, and mainly includes:
  • a request receiving unit 21 configured to receive a document management request
  • the request parsing unit 22 is configured to determine that the document management request is a document management batch processing request, and obtain corresponding document management batch processing information from the document management batch processing request.
  • the request parsing unit 22 may specifically include:
  • a message body format identifying unit 221, configured to parse a message header of the document management batch processing request, to identify a message body format of the document management batch processing request;
  • the batch processing information obtaining unit 222 is configured to decode the message body of the document management request according to the message body format, and obtain corresponding document management batch processing information.
  • the batch processing information obtaining unit 222 may specifically include:
  • the batch addition/modification processing information obtaining sub-unit 2221 is configured to: when the message body format recognized by the message body format identifying unit is a document management batch addition/modification request message body format, according to the document management batch increase/modification request The message body format decodes the message body of the document management request, and obtains corresponding document management batch increase/modification processing information;
  • the batch query processing information obtaining sub-unit 2222 is configured to: when the message body format recognized by the message body format identifying unit is a document management batch query request message body format, according to the document management batch query request message body format decoding The message management request message body obtains the corresponding document management batch query processing information;
  • a batch deletion processing information obtaining sub-unit 2223 configured to: when the message body format recognized by the message body format identifying unit is a document management bulk deletion request message body format, decoding the file according to the document management bulk deletion request message body format The message management request message body obtains the corresponding document management batch deletion processing information;
  • the batch mobile processing information obtaining sub-unit 2224 is configured to: when the message body format recognized by the message body format identifying unit is a document management batch mobile request message body format, decode the message according to the document management bulk mobile request message body format The message management request message body obtains the corresponding document management batch movement processing information.
  • the request processing unit 23 is configured to manage the batch processing information according to the document, and execute a corresponding document management batch processing operation.
  • the request processing unit may specifically include:
  • the batch addition/modification request processing sub-unit 231 is configured to perform batch management addition/modification processing operations according to the document management batch addition/modification processing information
  • a batch query request processing sub-unit 232 configured to manage batch query processing information according to the document, and perform a document management batch query processing operation
  • a batch deletion request processing sub-unit 233 configured to perform a document management batch deletion processing operation according to the document management batch deletion processing information
  • the batch movement request processing sub-unit 234 is configured to perform a document management batch movement processing operation according to the document management batch movement processing information.
  • the response processing unit 24 is configured to assemble and generate a document management batch processing response message according to the execution result information of the document management batch processing operation according to the corresponding document management batch processing operation response message format; and send the document management batch processing to the document management client Reply message.
  • the response processing unit 24 may specifically include:
  • the response message generating unit 241 is configured to assemble and generate a document management batch processing response message according to the execution result information of the document management batch processing operation according to the corresponding document management batch processing operation response message format;
  • the response message sending unit 242 is configured to send the document management batch processing response message to the document management client.
  • the embodiment of the present invention adopts a batch processing operation indication that multiple clients need to perform multiple batch processing on a plurality of documents or a single document, and sends a batch processing request to the server through a document management, and the server is in the server.
  • the server is in the server.
  • the program can be stored in a computer readable storage medium, which, when executed, can 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)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (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

一种文档管理方法、 系统以及相关设备 本申请要求了 2007年 12月 14日提交的， 申请号为 200710032635.X发明 名称为 "一种文档管理方法、 系统以及相关设备" 的中国申请的优先权， 其全 部内容通过引用结合在本申请中。 技术领域 本发明涉及信息管理技术领域，具体涉及可扩展标记语言（XML, extensible Markup Markup Language )文档管理请求方法和相应的 XML文档管理方法、 XML文档管理系统以及 XML文档管理客户端和文档管理服务器。 背景技术
XML是一套定义语义标记的规则， 所定义的标记将文档分成许多部件并对 这些部件加以标识，符合 XML规则的文档即为 XML文档。 XML文档具有易于 阅读和编写的优点， 是网络应用中描述数据和交换数据的理想格式。
XML文档管理客户端 （ XDMC: XML Document Management Client )可使 用文档管理请求，在 OMA(Open MOBIE Alliance,开放移动联盟)标准中的 XML 配置访问协议（XCAP: XML Configuration Access Protocol ) 中定义的 "GET，，、 "PUT" , "DELETE" 等方法， 实现对 XML 文档管理服务器 （XDMS: XML Document Management Server ) 上以 XML格式存储的应用配置数据进行查询、 增加和修改、 删除等操作。
在实际应用中， 用户可通过上述三种请求操作实现对 XDMS的单个文档或 单个文档中的单个节点进行相应的查询、 增加和修改、 删除等操作。 而当用户 需要进行对 XDMS的多个文档或单个文档中的多个节点进行相应的查询、 增加 和修改、删除等操作时，需在 XDMC与 XDMS之间多次反复调用相应请求操作 完成对多个文档或单个文档下的多个节点的操作。
发明内容
本发明实施例提供了一种可扩展标记语言文档管理请求方法包括： 接收用 户的文档管理批量处理请求指示； 根据所述文档管理批量处理请求指示生成文 档管理批量处理请求； 将所述文档管理批量处理请求发送给服务器。
以及相应的可扩展标记语言文档管理方法， 包括： 接收文档管理请求； 确 定所接收到的文档管理请求为文档管理批量处理请求； 从所述文档管理批量处 理请求中获取相应的文档管理批量处理信息； 根据所述文档管理批量处理信息 , 执行相应的文档管理批量处理操作。
本发明实施例还提供了一种可扩展标记语言文档管理客户端， 包括： 用户 操作单元， 用于接收用户的批量处理请求指示； 请求生成单元， 用于根据所述 文档管理批量处理请求指示生成文档管理批量处理请求； 请求发送单元， 用于 将所述文档管理批量处理请求发送给服务器。
和一种可扩展标记语言文档管理服务器， 包括： 请求接收单元， 用于接收 文档管理请求； 请求解析单元， 用于确定所述文档管理请求为文档管理批量处 理请求， 并从所述文档管理批量处理请求中获取相应的文档管理批量处理信息； 请求处理单元， 用于根据所述文档管理批量处理信息， 执行相应的文档管理批 量处理操作。
以及一种可扩展标记语言文档管理系统， 包括客户端和服务器， 所述客户 端包括： 用户操作单元， 用于接收用户的批量处理请求指示； 请求生成单元， 用于根据所述文档管理批量处理请求指示生成文档管理批量处理请求； 请求发 送单元， 用于将所述文档管理批量处理请求发送给服务器； 所述服务器包括： 请求接收单元， 用于接收文档管理请求； 请求解析单元， 用于确定所述文档管 理请求为文档管理批量处理请求， 并从所述文档管理批量处理请求中获取相应 的文档管理批量处理信息； 请求处理单元， 用于根据所述文档管理批量处理信 息， 执行相应的文档管理批量处理操作。
上述技术方案中采用客户端将需要对多个文档或单个文档下的多个节点的 批量处理操作指示， 通过一条文档管理批量处理请求发送给服务端， 服务端在 确定为文档管理批量处理请求时， 获取相应的文档管理批量处理信息并执行相 应的文档管理批量处理操作； 由于客户端只需要发送一条信令来进行多个文档 或单个文档下的多个节点的批量处理操作， 减小了操作时延， 提高了操作效率， 提高了数据操作的可靠性。 附图说明 例或现有技术描述中所需要使用的附图作筒单地介绍， 显而易见地， 下面描述 中的附图仅仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付 出创造性劳动的前提下， 还可以根据这些附图获得其他的附图。 图 1是本发明实施例的 XML文档管理请求方法流程示意图；
图 2是本发明实施例的 XML文档管理方法流程示意图；
图 3是本发明实施例的 XML文档管理批量增加 /修改（ PUTS )处理方法流 程示意图；
图 4是本发明实施例的 XML文档管理批量查询 （GETS )处理方法流程示 意图；
图 5是本发明实施例的 XML文档管理批量删除（DELETES )处理方法流 程示意图；
图 6是本发明实施例的 XML文档管理批量移动（ MOVE )处理方法流程示 意图；
图 7是本发明实施例的 XML文档管理系统的组成示意图；
图 8是本发明实施例的 XML文档管理客户端的结构示意图；
图 9是本发明实施例的 XML文档管理服务器的结构示意图。 具体实施方式
下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进行清 楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是 全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没有作出创造 性劳动前提下所获得的所有其他实施例， 都属于本发明保护的范围。
本发明实施例提供了一种文档管理请求方法， 客户端向服务器发送对多个 文档或单个文档下的多个节点进行处理操作的文档管理批量处理请求， 服务器 在确定为文档管理批量处理请求时， 进行相应文档管理批量处理操作。 本发明 实施例还提供了相应的 XML文档管理方法、 XML文档管理系统、 XML文档管 理客户端和 XML文档管理服务器。 下面分别进行详细描述。 参考图 1 , 是本发明实施例的 XML文档管理请求方法流程示意图， 包括步 骤：
Al、 接收用户的文档管理批量处理请求指示。
此处， 所述文档管理批量处理请求为文档管理批量增加 /修改请求指示， 或 为文档管理批量查询请求指示， 或为文档管理批量删除请求指示， 或为文档管 理批量移动请求指示。 对应于现有的 XML配置访问协议中定义的 PUT (增加 / 修改） 方法， 所述文档管理批量增加 /修改请求指示是指用户需要对多个文档或 单个文档下的多个节点同时进行增加或修改的操作需求， XDMC可通过提供给 用户的操作界面获取用户的批量增加 /修改请求指示。 对应于现有的 XML配置 访问协议中定义的 GET (查询）方法， 所述文档管理批量查询请求指示是指用 户需要对多个文档或单个文档下的多个节点同时进行查询的操作需求， XDMC 可通过提供给用户的操作界面获取用户的批量查询请求指示。 对应于现有的 XML配置访问协议中定义的 DELETE (删除）方法， 所述文档管理批量删除请 求指示是指用户需要对多个文档或单个文档下的多个节点同时进行删除操作需 求， XDMC可通过提供给用户的操作界面获取用户的批量增加 /修改请求指示。 在现有的 XML文档管理方法中， 实现单个节点的移动是通过 PUT和 DELETE 两条信令消息实现的， 本发明实施例所述的文档管理批量移动请求指示是指用 户需要对多个文档或单个文档下的多个节点同时进行移动的操作需求， XDMC 可通过提供给用户的操作界面获取用户的批量移动请求指示。
A2、 根据所述文档管理批量处理请求指示生成文档管理批量处理请求。 此处， 具体实现时， 考虑到与现有的 XML 配置访问协议中定义 'PUT' 、 'GET' 以及 'DELETE' 信令方法的结构相兼容， 以及符合协议标准的定义习 惯， 本发明实施例所述的文档管理批量处理请求主要由以下几部分组成：
1、 请求行
请求行包括： Method (方法名）、 Request-URL 以及 HTTP- Version ( HTTP 协议版本号）。
1 ) Method (方法名）描述与现有技术类似， 本发明实施例中定义文档管理 批量增加 /修改处理请求的方法名为 PUTS, 文档管理批量查询处理请求的方法 名为 GETS, 文档管理批量删除处理请求的方法名为 DELETES, 文档管理批量 移动处理请求的方法名为 MOVE。 显然以上方法名的定义主要是为了区别与现 有的方法名以及具备一定的可读性， 本领域技术人员应该明白， 选用其他字符 也是可以达到相同的目的的。
2 )在现有技术中， 标准 XCAP信令 Request-URI格式为： XCAP Root + AUID + " users ，， + XUI + filename 。 例 如 ： http://xcap.example.eom/org.openmobilealliance.user-profile/users/sip:zhangshan@h uawei.com/index.xml , 其中： XCAP Root 7(7 http://xcap.example.com/, AUID是 org . openmobilealliance.user-profile , "users"是常量, 表示接下来是用户信 ' ( XUI ), XUI是 sip: user @huawei.com( sip:表示 XUI是 tel uri , huawei.com是 XDMS 归属域名 ), 文件名为 index.xml。
为支持批量处理， 本发明要求用一个批处理标记 "batch" 替代文件名 （也 可以用其它字符串标记）。如果需要同时操作多个业务， Request-URI中的 AUID 换成一个不表示任何具体业务的特定字符串， 如 "00" , 把具体要操作的业务放 到后面以 "xs:schema，， 开始的消息体中。 若当前只操作一种业务， 则可以在 Request-URI中存放真实的业务标识。
基于上述机制， XCAP批处理请求行的 Request-URI可以表示为：
http://xcap.example om/00/users/sip:zhangshan@huawei.com/batch 。
Figure imgf000007_0001
Figure imgf000007_0002
每种 XCAP批量处理请求的消息体格式不同， Content-Type也就不同。本发 明约定几种批处理请求的 Content-Type定义如下：
GETS: application/gets+xml (对应文档管理批量查询）；
PUTS: application/puts+xml (对应文档管理批量增加 /修改）；
DELETES： application/deletes+xml (对应文档管理删除查询）；
MOVE: application/move+xml (对应文档管理批量移动）；
以上 Content-Type也可以定义成其它值，但需区别于 0MA已经定义的类型。
3、 请求消息体 每种批量处理请求信令的请求消息体格式是不同的， 后文对此将有相应描 述。
批处理请求消息的命名空间 （NameSpace和 targetNamespace )在消息体起 始部分描述。 例如：
<xs： schema xmlns:xs="http：〃 www. w3.org/2001/XMLSchema" xmlns="com:huawei:puts" targetNamespace="com:huawei:puts" elementForaiDefault="qualified">,将 PUTS请求消息体的命名空间（ NameSpace ) 为 "com:huawei:puts"。
A3、 将所述文档管理批量处理请求发送给服务器。
此处， XDMC可参考发送现有的其他类型的文档管理请求的方式将所述文 档管理批量处理请求发送给 XDMS。
通常 XDMC会收到 XDMS对文档管理批量处理请求的处理结果应答消息， 在后续实施描述中， 将会说明 XDMS对文档管理批量处理请求的处理结果应答 消息对应于不同类型的文档管理批量处理请求文档管理批量处理消息的消息格 式是不同的， 后文将在具体类型的文档管理批量处理的实施例描述中对 XDMC 对文档管理批量处理消息的接收以及处理过程进行相应描述。
参考图 2, 是本发明实施例的 XML文档管理方法流程示意图， 包括步骤：
Bl、 接收来自客户端的文档管理请求。
此步骤可参考现有文档管理请求的接收方法进行。
B2、 确定所接收到的文档管理请求为文档管理批量处理请求。
此处， XDMS可根据与 XDMC共同遵守的约定， 通过解析收到的文档管理 请求来确定其类型。 例如文档管理批量处理请求采用新定义的方法名来标识， 对应各种类型的文档管理批量处理请求定义由相应的方法名来标识。
B3、 从所述文档管理批量处理信息中获取相应的文档管理批量处理信息。 此处， 在确定收到的文档管理请求的类型为文档管理批量请求后， XDMS 首先解析所述文档管理请求的消息头， 通过识别 Content-Type类型 （每种类型 的文档管理批量处理请求对应有唯一的 Content-Type 类型标识）， 以及根据 XDMS与 XDMC约定的对应该 Content-Type类型的消息体格式解码所述文档管 理批量处理请求的消息体， 获取相应的文档管理批量处理信息。
本发明实施例中不同类型的文档管理批量处理请求的消息体格式是不同 的， 对应具体类型的文档管理批量处理请求， XDMC基于与 XDMS约定的消息 体格式编码生成相应的文档管理批量处理请求， 同时， XDMC通过消息头中的 Content-Type 类型标识消息体格式类型， XDMS接收到文档管理批量处理请求 后， 解析其消息头中的 Content-Type类型标识， 获取标识消息体格式类型， 进 而根据对应该消息格式类型的消息体格式解码所述文档管理批量处理请求的消 息体。
B4、 根据所述文档管理批量处理信息， 执行相应的文档管理批量处理操作。 B5、 向客户端返回文档管理批量处理应答消息。
此处， 基于文档管理批量处理操作的执行结果信息， 按照相应的文档管理 批量处理操作应答消息格式组装生成文档管理批量处理应答消息， 并向文档管 理客户端发送所述文档管理批量处理应答消息。
本发明实施例所述的文档管理批量处理应答消息主要由以下几部分组成：
1、 应答状态行
Figure imgf000009_0001
2、 应答消息头
你 类型 i 明 备注
Etag entity-tag Jf ]于比较 参 考 同一 源的不 [RFC2616] section 14.19, 同实 14.24, 14.26, 14.44
[XCAP] section 7.10,
8.5
Content-Type media-type 4ι %定消息
体的 类 型
Content-Length 1*DIGIT 消息体的 参 考 长度 [RFC2616] section 14.13 本发明实施例描述的四种批处理信令的应答消息体 Content-Type定义如下: GETS: application/gets-result+xml
PUTS： application/puts-result+xml
DELETES: NA
MOVE: NA
以上 MIME类型也可以约定其它标记。
Content-Length 用 "（..·）" 描述。
3、 应答消息体
根据请求返回相应的内容， 每种批处理信令的应答消息体格式在后文将有 相应描述。
上述方法实施例中采用客户端将需要对多个文档或单个文档下的多个节点 的批量处理操作指示， 通过一条文档管理批量处理请求发送给服务端， 服务端 在确定为文档管理批量处理请求时， 获取相应的文档管理批量处理信息并执行 相应的文档管理批量处理操作； 由于客户端只需要发送一条信令来进行多个文 档或单个文档下的多个节点的批量处理操作， 减小了操作时延， 提高了操作效 率， 提高了数据操作的可靠性。
参考图 3, 是本发明实施例的 XML文档管理批量增加 /修改（PUTS )处理 方法流程示意图， 下面对其进行详细描述。
步骤 s401 , XDMC向 XDMS发送文档管理批量增加 /修改处理请求。
所述文档管理批量增加 /修改处理请求信令格式如下：
1、 请求行
Figure imgf000010_0001
PUTS信令请求行如下: PUTS http://xcap.example.eom/00/users/sip:XXX@huawei.corn/batch HTTP/1.1
其中， "batch" 表示批量增加或修改文档， "00" 是 auid替代符， 表示操作 的具体业务在消息中定义, XXX表示发起请求的用户号码， "sip:"表示这是一个 sip uri, "@huawei.com" 为用户 XXX归属的 XDMS域名。
2、 请求消息头
PUTS信令请求消息头如下：
Content-Type: application/puts+xml;
Content-Length: (...)
application/puts+xml是 PUTS请求的消息体格式。 可以是其它标记， 但须有 别于 OMA其它定义。
3、 请求消息体
PUTS请求消息体格式：
<?xml version="1.0" encodings "UTF- 8 "?>
<xs： schema xmlns :xs= "http：〃 www. w3.org/2001/XMLSchema" xmlns="com:huawei:puts" targetNamespace="com:huawei:puts" elementForaiDefault=" qualified ">
<xs: element name="list">
<xs :complexType>
<xs:sequence>
<xs: element name="auid" type="auidType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<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' V〉 </xs: complexTypo
<xs: complexType name="fileType">
<xs:sequence>
<xs: element name="node" type="nodetype" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs: attribute name="name" type="xs: string" use: "required' V〉 <xs: attribute name="ctype" type="xs: string" use= "required' V〉 <xs: attribute name="etag" type="xs: string" use="optional"/>
</xs: complexTypo
<xs: complexType name: " nodetype "〉
<xs:sequence>
<xs:any namespace="##any" processContents="lax" maxOccurs="unbounded"/>
</xs:sequence>
<xs: attribute name="uri" type: "xs: string" use= "required' V〉
</xs: complexTypo
</xs:schema>
说明：
PUTS请求消息体是针对 PUTS请求消息的批量处理特性定义的；
"com:huawei:puts"为 PUTS请求消息体的命名空间 （ namespace ), 可以是其 它约定值；
PUTS请求消息体分 list、 auid、 file, node四级， 可以是其它约定属性名： list为根节点， auid表示要处理的业务， file表示要处理的文档， node表示要处 理的节点；
根据 schema定义， 可以对多个业务（用 AUID表示）分别执行新增或修改 多个文档的操作， 也可以对同一篇文档执行增加或修改多个节点的操作；
对于同一请求的增加或修改操作信息， 可以也在一个 list标签中表达； auidType: name为 auid的名字；
fileType: name为文档名， ctype为文档的 cType类型， etag为文档版本号。 对 file中 ctype属性的特另1 J约定： ctype="application/xcap-el+xmr表示修改节点元 素， ctype="application/xcap-att +xml"表示修改节点属性， 也可以约定其它值。
nodetype: uri属性表示要插入或替换的结点在 xml文档中的路径， uri值采 用 Xpath语法。
PUTS批量处理请求消息的一个示例如下：
PUTS请求消息
PUTS http://xcap.example.eom/00/users/sip:13500012345@huawei.com/batch HTTP/1.1
Content-Type: "application/puts+xml"；
Content-Length: (...)
<list xmlns="com:huawei:puts">
<auid name="ims-pim" >
<file name="index.xml" ctype="application/ims-pim+xml"> <ims-pim xmlns="com:huawei:ims-pim">
<display-name〉张三 </display-name〉
<tel>58012700</tel>
</ims-pim>
</file>
</auid>
<auid name="resource-lists">
<file name="friend.xml" ctype="application/xcap-el+xml etag="abbbbcc">
<node uri=71ist/entry[@id=%22m_b6ZCxl%22]">
<entry id="m_b6ZCxl " xmlns="com:huawei:resource-lists"> <display-name> xiaoxiong</display-name>
</entry>
</node> <node uri=71ist/entry[@uri=%2213509090999%22]">
<entry uri=" 13509090999" xmlns="com:huawei:resource-lists">
<display-name> xiaomao</display-name>
</entry>
</node>
<node uri=71ist/entry[@id=%22m_b6ZA8j%22]">
<entry id="m_b6ZA8j" uri=" 13509090999" xmlns="com:huawei:resource-lists">
<display-name> xiaoqiang</display-name>
</entry>
</node>
</file>
</auid>
</list>
说明：
此例表示用户 13500012345请求修改 ims-pim (个人信息的 auid ) 的文档 index.xml的同时, 修改 resource-lists (分组歹1 J表的 auid ) 的文档 friend.xml; ims-pim 的 ctype 为 "application/ims-pim+xml" , 这有另1 J于消息体的
"application/puts+xml"；
ims-pim 的 namespace 为 "com:huawei:ims-pim" , 也有另1 J于消息体的
" com: huawei: puts"；
对 index.xml的修改， 未指定版本号 etag, 说明缺省有权限；
friend.xml的 ctype 7(7 "application/xcap-el+xml" , 表示修改节点；
friend.xml的 etag为 "abbbbcc" , 表示服务端要做版本控制， 版本号不同则 不允许修改节点；
节点路径在通过 node标签中的 uri属性描述；
node下的每对 entry描述的是 resource-lists中的 entry节点。 步骤 s402, 对 PUTS批量处理请求按照 PUTS请求消息格式进行解码， 获 取 PUTS批量处理信息。
XDMS 解析 PUTS 批量处理请求的消息头， 获取 Content-Type 类型为 application/puts+xml, 进而根据对应的 PUTS消息体格式解码 PUTS批量处理请 求消息体， 获取 PUTS批量处理信息。
步骤 s403 , 根据 PUTS批量处理信息， 执行 PUTS批量处理操作，完成相应 的文档信息批量增加或修改。
步骤 s404, 对 PUTS批量处理的结果按照 PUTS应答消息格式进行编码。
PUTS应答消息组成如下：
1、 应答状态行
格式： HTTP- Version + Status-Code + Reason-Phrase
HTTP版本， HTTP-Version: HTTP/1.1
状态码， Status-Code: 200或 500
Reason-Phrase: Status-Code取 200时为 OK, 取 500时为 NOK。
2、 应答消息头
Content-Type: application/puts-result+xml
Content-Length: (··· )
application/puts-result+xml是 PUTS应答消息体格式。 可以是其它标记， 但 须有别于 OMA其它定义。
3、 应答消息体
PUTS应答消息体格式如下：
<?xml version="1.0" encodings "UTF- 8 "?>
<xs： schema xmlns :xs= "http：〃 www. w3.org/2001/XMLSchema" xmlns="com:huawei:puts-result" xmlns:nsl="com:huawei:puts-result" targetNamespace="com:huawei:puts-result" elementFormDef ault= ' ' qualified ' ' >
<xs: element name="list">
<xs :complexType>
<xs:sequence>
<xs: element name="auid" type="auidType" maxOccurs="unbounded"/> </xs:sequence>
</xs:complexType>
</xs:element>
<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' V〉 </xs: complexTypo
<xs: complexType name="fileType">
<xs:sequence>
<xs: element
Figure imgf000016_0001
<xs: element name="etag" type="xs: string "/>
</xs:sequence>
<xs: attribute name="name" type="xs: string" use: "required' V〉 </xs: complexTypo
</xs:schema>
PUTS应答消息体是针对 PUTS应答消息的批处理特性定义的， 是对 OMA XCAP的补充；
"com:huawei:puts-result" 为 PUTS应答消息的命名空间 （NameSpace ), 可 以是其它约定值；
PUTS应答消息体包含 list、 auid和 file三级， list为根节点， auid描述业务 信息， file描述文档信息， 也可以是其它约定元素名；
auid节点： name为 auid名字 , ctype为 auid对应的 schema;
file节点： name 为文档名， result为每个文档操作的返回码（参考 OMA XCAP PUT信令中对返回码的定义）， etag为文档新的版本号；
创建文档或节点成功 result取 201 , 修改文档或节点成功 result取 200。 PUTS批量处理应答消息的一个示例如下：
HTTP/1.1 200 OK Content-Type: "application/puts-result+xml"；
Content-Length: (...)
<list xmlns="com:huawei:puts-result">
<auid name="ims-pim">
<file name="index.xml">
<result>201 </result>
<etag>reeeedd</etag>
</file>
</auid>
<auid name="resource-lists">
<file name="friend.xml">
<result>200</result>
<etag>reeeedd</etag>
</file>
</auid>
</list> 从上例可以看出， 创建和修改返回码（result ) 不同， 在这点上遵从 OMA 定义。
步骤 s405 , 向客户端返回应答消息。
参考图 4, 是本发明实施例的 XML文档管理批量查询 （GETS )处理方法 流程示意图， 下面对其进行详细描述。
步骤 s501 , 发送 GETS批量处理请求。
所述文档管理批量查询处理请求信令格式如下:
1、 请求行
类型 说明
Method token XCAP请求方法，取值 GETS
Request-URI HTTP URI 指定请求操作的 XCAP资源。
HTTP- Version HTTP版本，
取值 HTTP/1.1 GETS信令请求行如下：
GETS http://xcap.example.eom/00/users/sip:XXX@huawei.corn/batch HTTP/1.1
其中， "batch" 表示批量获取文档， "00" 是 auid替代符， 表示操作的具体 业务在消息中定义, XXX表示发起请求的用户号码， "sip:"表示这是一个 sip uri, " @huawei.com" 为用户 XXX归属的 XDMS域名。
2、 请求消息头
GETS信令请求消息头如下：
Content-type: application/gets+xml
Content-Length: ( ··· )
application/gets+xml是 GETS请求的消息体格式。 可以是其它标记， 但须有 别于 OMA其它定义。
3、 请求消息体
GETS请求消息体格式：
<?xml version="1.0" encodings "UTF- 8 "?>
<xs： schema xmlns :xs= "http：〃 www. w3.org/2001/XMLSchema" xmlns="com:huawei:gets" targetNamespace="com:huawei:gets" elementForaiDefault=" qualified ">
<xs: element name="list">
<xs :complexType>
<xs:sequence>
<xs: element name="auid" type=" auidType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs: complexType name=" fileType ">
<xs: attribute name="name" type="xs: string" use: "required' V〉 </xs: complexTypo
<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' V〉 </xs: complexTypo
</xs:schema> 说明：
GETS请求消息体是针对 GETS请求消息的批处理特性定义的， 是对 OMA XCAP的补充；
"com:huawd:gets' '为 GETS请求消息体的命名空间 （ namespace ), 可以是其 它约定值；
GETS请求消息体分 list、 auid, file三级， 可用来描述一次性获取多个业务 的多个文档。 其中， list 为根节点， auid表示要处理的业务， file表示要处理的 文档；
auidType中 name为 auid的名字；
fileType中 name为文档名， 可以是通配符， 如用 "*，， 表示获取所有文档； auid下既指定具体文档名又指定文档名为 "*"时， 则取该用户 auid下的所 有文档。
GETS批量处理请求消息的一个示例如下：
GETS请求消息
GETS http://xcap.example.eom/00/users/sip:13500012345@huawei.com/batch HTTP/1.1
Content-type: application/gets+xml
Content-Length: ( ··· )
<list xmlns="com:huawei:gets">
<auid name="ims-pim">
<file name="index.xml"/> </auid>
<auid name="resource-lists">
<file name="file_001.xml"/>
<file name="*"/>
</auid>
</list>
上例表示用户 13500012345 请求获取 ims-pim 下的 index.xml 和 resource-lists下所有文档。
步骤 s502, 对 GETS批量处理请求按照 GETS请求消息格式进行解码， 获 取 GETS批量处理信息。
XDMS 解析 GETS 批量处理请求的消息头， 获取 Content-Type 类型为 application/gets+xml, 进而根据对应的 GETS消息体格式解码 GETS批量处理请 求消息体， 获取 GETS批量处理信息。
步骤 s503 , 根据 GETS批量处理信息， 执行 GETS批量处理操作，完成相应 的文档信息批量查询。
步骤 s504, 对 GETS批量处理的结果按照 GETS应答消息格式进行编码。
GETS应答消息组成如下：
1、 应答状态行
格式： HTTP- Version + Status-Code + Reason-Phrase
HTTP版本， HTTP- Version: HTTP/1.1
状态码， Status-Code: 200或 500
Reason-Phrase: Status-Code取 200时为 OK, 取 500时为 NOK。
2、 应答消息头
Content-Type: application/gets-result+xml
Content-Length: ( ··· )
application/gets-result+xml是 GETS应答消息体格式。 可以是其它标记， 但 须有别于 OMA其它定义。
3、 应答消息体
GETS应答消息体格式：
<?xml version="1.0" encodings "UTF- 8 "?> <xs： schema xmlns :xs= "http：〃 www. w3.org/2001/XMLSchema xmlns="com:huawei:gets-result" targetNamespace="com:huawei:gets-result elementForaiDefault=" qualified ">
<xs: element name="list">
<xs :complexType>
<xs:sequence>
<xs: element name="auid" type="auidType maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs: element name="file">
<xs :complexType>
<xs:sequence>
<xs:any namespace="##other" processContents="lax minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs: attribute
Figure imgf000021_0001
<xs: attribute name="etag" type="xs: string" use="required"/>
</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' V〉 <xs: attribute name="ctype" type="xs: string" use= "required' V〉 </xs: complexTypo
</xs:schema> 说明：
GETS应答消息体是针对 GETS应答消息的批处理特性定义的， 是对 OMA XCAP的补充；
"com:huawd:gets-result"为 GETS应答消息体命名空间 （ NameSpace ), 可以 是其它约定值；
GETS应答消息体消息体分 list、 auid和 file三级， list为根节点， auid描述 业务， file描述文档， 也可以是其它约定名称；
auid节点： name为 auid名字 , ctype为 auid对应的 schema (即消息体格式 ); file节点： name 为文档名, etag为文档版本号。
GETS批量处理应答消息的一个示例如下：
GETS应答消息
HTTP/1.1 200 OK
Content-Type: "application/gets-result+xml"
Content-Length: ( ··· )
<list xmlns="com:huawei:gets-result">
<auid name="ims-pim" ctype= " application/ims-pim+xml " >
<file name="index.xml" etag="dffffgg">
<ims-pim xmlns="com:huawei:ims-pim">
<name>bob</name>
<tel>58012700</tel>
</ ims-pim>
</file>
</auid>
<auid name= "resource-lists" ctype=" application/ resource-lists+xml">
<file name="file_001.xml" etag="reeeedd">
<contact-profiles xmlns="com:huawei: resource-lists ">
<name>tom</name>
<tel>58012701</tel>
</contact-profile> </file>
<file name="file_002.xml" etag="rccccff">
<contact-profiles xmlns="com:huawei: resource-lists ">
<name>bill</name>
<tel>58012702</tel>
</contact-profiles>
</file>
</auid>
</list>
此例返回 "ims-pim" 中的 index.xml , 以及 "resource-lists" 中的仅有的 两篇文档。
步骤 s505 , 向客户端返回应答消息。
参考图 5 , 是本发明实施例的 XML文档管理批量删除（ DELETES )处理方 法流程示意图， 下面对其进行详细描述。
步骤 s601 , 发送 DELETES批量处理请求。
所述文档管理批量删除处理请求信令格式如下：
1、 请求行
Figure imgf000023_0001
DELETES信令请求行如下:
DELETES http://xcap.example.eom/00/users/sip:XXX@huawei.com/batch HTTP/1.1
其中， "batch" 表示批量删除文档或节点， "00" 是 auid替代符， 表示操作 的具体业务在消息中定义， XXX表示发起请求的用户号码， "sip:" 表示这是一 个 sip uri, " @huawei.com" 为用户 XXX归属的 XDMS域名。
2、 请求消息头 DELETES信令请求消息头如下：
Content-Type: application/deletes+xml;
Content-Length: (...)
application/deletes+xml是 DELETES请求的消息体格式。 可以是其它标记， 但须有别于 OMA其它定义。
3、 请求消息体
DELETES请求消息体格式：
<?xml version="1.0" encodings "UTF- 8 "?>
<xs： schema xmlns :xs= "http：〃 www. w3.org/2001/XMLSchema' xmlns="com:huawei:deletes" targetNamespace= " com: huawei： deletes ' elementForaiDefault=" qualified ">
<xs: element name="list">
<xs :complexType>
<xs:sequence>
<xs: element name="auid" type=" auidType' maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs: complexType name=" fileType ">
<xs:sequence>
<xs: element name="node" type: "xs: string" minOccurs="0' maxOccurs="unbounded"/>
</xs:sequence>
<xs: attribute name="name" type="xs: string" use: "required' V〉 <xs: attribute name="etag" type="xs: string" use="optional"/>
</xs: complexTypo
<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' V〉 </xs: complexTypo
</xs:schema> 说明：
DELETES请求消息体是针对 DELETES请求消息的批处理特性定义的。 "com:huawei:deletes"为 DELETES请求消息的命名空间（NameSpace ), 可以 是其它约定值；
DELETES请求消息体分 list、 auid, file, node四级， list为根节点， auid为 业务标识， file表示删除的文档， node表示删除的节点；
按 schema定义， 可以同时删除多个业务的文档， 也可以同时删除某业务下 的多个文档或所有文档 （如用通配符 "*" 作为文档名）， 或者删除一篇文档的 多个节点；
auidType: name为 auid的名字；
fileType: name为文档名, etag为文档版本号；
node: 节点的 XPATH路径。
DELETES批量处理请求消息的一个示例如下：
DELETES请求消息
DELETES
http://xcap.example.eom/00/users/sip:13500012345 @ huawei.com/batch HTTP/ 1.1
Content-type: application/deletes+xml
Content-Length: ( ··· )
<list xmlns="com:huawei:deletes">
<auid name= "resource-lists "/>
<file name="file_001.xml" etag="eddddkk">
<node>/resource-lists/list[@name="friends"]</node>
<node>/resource-lists/list[@name="class"]</node>
</file> <file name="file_002.xml" etag="abbbbcc"/>
</auid>
<auid name="test"xfile name="file_003" etag="addddee" /></auid> <auid name="test2"xfile name="*"/x/auid>
</list> 说明：
此例表示用户 13500012345请求执行文档批量删除操作；
在 resource-lists中， 删除文档 file_002.xml 和 file_001.xml的两个节点， 节 点 的 XPATH 路 径 分 另1 J 为 /resource-lists/list[@name="friends"] 和 /resource-lists/list[@name="class"];
在 test中， 删除文档 file_003;
在 test2中， 删除所有文档。
步骤 s602,对 DELETES批量处理请求按照 DELETES请求消息格式进行解 码， 获取 DELETES批量处理信息。
XDMS解析 DELETES批量处理请求的消息头， 获取 Content-Type类型为 application/ddetes+xml, 进而根据对应的 DELETES消息体格式解码 DELETES 批量处理请求消息体， 获取 DELETES批量处理信息。
步骤 s603 , 根据 DELETES批量处理信息， 执行 DELETES批量处理操作, 完成相应的文档信息批量删除。
步骤 s604,对 DELETES批量处理的结果按照 DELETES应答消息格式进行 编码。
DELETES应答消息组成如下：
1、 应答状态行
格式： HTTP- Version + Status-Code + Reason-Phrase
HTTP版本， HTTP-Version: HTTP/1.1
状态码， Status-Code: 200或 500
Reason-Phrase: Status-Code取 200时为 OK, 取 500时为 NOK。
2、 应答消息头
Etag: "reeeedd" Content-Length: ( ··· )
DELETES应答消息无消息体， 因此不需要定义 Content-Type。
DELETES应答消息示例如下：
DELETES应答消息
HTTP/1.1 200 OK
Etag: "reeeedd"
Content-Length: 0 此应答消息表示批量删除成功， 存在节点删除的文档新版本号为 reeeedd。 步骤 s605 , 向客户端返回应答消息
参考图 6 , 是本发明实施例的 XML文档管理批量移动 （MOVE )处理方法 流程示意图， 下面对其进行详细描述。
步骤 s701 , 发送 MOVE批量处理请求。
所述文档管理批量移动处理请求信令格式如下：
1、 请求行
,你 类型 说明
Method token XCAP请求方法，取值 MOVE
Request-URI HTTP URI 指定请求操作的 XCAP资源。
HTTP-Versio n HTTP版本， 取值 HTTP/1.1
MOVE信令请求行如下:
MOVE
http://xcap.example om/resource-lists/users/sip:XXX@huawei.com/batch HTTP/1.1 其中， "batch" 表示批量移动文档中的节点， resource-lists表示操作的具体 业务， XXX 表示发起请求的用户号码， " sip: " 表示这是一个 sip uri , " @huawei.com" 为用户 XXX归属的 XDMS域名。
2、 请求消息头
MOVE信令请求消息头如下： Content-Type: application/mo ve+xml
Content-Length: (...)
application/mo ve+xml是 MOVE请求的消息体格式。 可以是其它标记， 但须 有别于 OMA其它定义。
3、 请求消息体
MOVE请求消息体格式：
<?xml version="1.0" encodings "UTF- 8 "?>
<xs： schema xmlns :xs= "http：〃 www. w3.org/2001/XMLSchema" xmlns="com:huawei:move" targetNamespace="com:huawei:move" elementForaiDefault=" qualified ">
<xs: element name="list">
<xs :complexType>
<xs:sequence>
<xs: element ref="node" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs: element name="node">
<xs :complexType>
<xs:sequence>
<xs: element name="from" type="fromType"/>
<xs: element name="to" type="toType"/>
</xs:sequence>
<xs: attribute name="seq" type="xs: string" use= "required' V〉
</xs:complexType>
</xs:element>
<xs: complexType name=" fromType ">
<xs: attribute name=" filename" type="xs: string" use="required"/> <xs: attribute name="etag" type="xs: string" use="optional"/>
</xs: complexTypo <xs:complexType name="toType">
<xs: attribute name=" filename" type="xs: string" use="required"/> <xs: attribute name="etag" type="xs: string" use="optional"/>
</xs: complexTypo
</xs:schema> 说明：
MOVE请求消息体是针对 MOVE请求消息的批处理特性定义的，是对 OMA XCAP的补充；
"com:huawei:MOVE" 是 MOVE请求消息的命名空间 （NameSpace ), 可以 是其它约定值；
MOVE请求消息体由 list和 1 ~N个 node节点构成，每个 node包含序号（ seq )、 源路径 (在 from标签中， 遵从 XPATH语法）、 目的路径 (在 to标签中， 遵从 XPATH语法 ), 可以是其它约定名称；
from: filename为源文档名， etag为源文档版本号；
to: filename为目的文档名， etag为目的文档版本号；
MOVE信令可用于在不同文档之间移动节点， 也可以在同一文档内部移动 节点。
MOVE批量处理请求消息的一个示例如下：
MOVE请求消息
MOVE
http://xcap.example om/resource-lists/users/sip: 13500012345 @huawei om/batch HTTP/1.1
Content-Type: application/move+xml
Content-Length: (...)
<list xmlns="com:huawei:move">
<node seq='T'〉
<from filename="listl .xml" etag="abbbbcc"> /resource- lists/list[@name="friends"]/entry[@uri=''sip:petri@example.com'']
</from>
<to filename="list2.xml" etag="abbbbdd">
/resource-lists/list[@name=''colleague'']/entry[@uri=Msip:petri@example omM]
</to>
</node>
</list>
此例表示用户 13500012345请求对 "resource-lists" 业务执行文档间节点移 动操作,将 listl.xml中分组名为 "friends"的节点 (
Figure imgf000030_0001
) 移动到文档 list2.xml的 "colleague" 分组下。
步骤 s702, 对 MOVE批量处理请求按照 MOVE请求消息格式进行解码， 获取 MOVE批量处理信息。
XDMS 解析 MOVE批量处理请求的消息头， 获取 Content-Type 类型为 application/move+xml, 进而根据对应的 MOVE消息体格式解码 MOVE批量处 理请求消息体， 获取 MOVE批量处理信息。
步骤 s703 , 根据 MOVE批量处理信息， 执行 MOVE批量处理操作,完成相 应的文档信息批量移动。
步骤 s704, 对 MOVE批量处理的结果按照 MOVE应答消息格式进行编码。
MOVE应答消息组成如下：
1、 应答状态行
格式： HTTP- Version + Status-Code + Reason-Phrase
HTTP版本， HTTP-Version: HTTP/1.1
状态码， Status-Code: 200或 500
Reason-Phrase: Status-Code取 200时为 OK, 取 500时为 NOK。
2、 应答消息头
Etag: "reeeedd"
Content-Length: (··· ) MOVE应答消息无消息体， 因此不需要定义 Content-Type。
MOVE应答消息的一个示例如下：
MOVE应答消息
HTTP/1.1 200 OK
Etag: "reeeedd"
Content-Length: 0
步骤 s705, 向客户端返回应答消息。 下面对与上述方法实施例相应的 XML文档管理系统、 XML文档管理客户 端以及 XML文档管理服务器进行详细说明。
参考图 7, 是本发明实施例的 XML文档管理系统的组成示意图， 该 XML 文档管理系统可执行上述方法实施例中的 XML文档管理请求方法以及 XML文 档管理方法， 具体实施时， 主要包括：
XML文档管理客户端 1 ,用于根据用户输入的文档管理批量处理请求指示， 生成文档管理批量处理请求， 并向服务器 2发送所述文档管理批量处理请求； 在接收到来自服务器 2 的文档管理批量处理应答消息时， 读取所述批量处理应 答消息中携带的状态码， 并根据所述批量处理应答消息的消息头识别是否存在 消息体， 若存在， 则根据相应的批量处理应答消息体格式对消息体进行解码， 获取文档管理批量处理结果信息；
XML文档管理服务器 2, 用于接收文档管理请求， 确定所述文档管理请求 为文档管理批量处理请求， 从所述文档管理批量处理请求中获取相应的文档管 理批量处理信息， 并根据所述文档管理批量处理信息， 执行相应的文档管理批 量处理操作； 基于文档管理批量处理操作的执行结果信息， 按照相应的文档管 理批量处理操作应答消息格式组装生成文档管理批量处理应答消息， 并向文档 管理客户端 1发送所述文档管理批量处理应答消息。
参考图 8, 是本发明实施例的 XML文档管理客户端的结构示意图， 该客户 用户操作单元 11 , 用于接收用户的批量处理请求指示；
请求生成单元 12, 用于根据所述文档管理批量处理请求指示生成文档管理 批量处理请求；
请求发送单元 13, 用于将所述文档管理批量处理请求发送给服务器； 应答消息接收单元 14, 用于接收来自服务器的批量处理应答消息； 应答消息处理单元 15, 用于读取所述批量处理应答消息中携带的状态码， 并根据所述批量处理应答消息的消息头识别是否存在消息体， 若存在， 则根据 相应的批量处理应答消息体格式对消息体进行解码， 获取文档管理批量处理结 果信息。
参考图 9是本发明实施例的 XML文档管理服务器的结构示意图，该服务器 主要用于执行上述方法实施例中的 XML文档管理方法， 主要包括：
请求接收单元 21 , 用于接收文档管理请求；
请求解析单元 22, 用于确定所述文档管理请求为文档管理批量处理请求， 并从所述文档管理批量处理请求中获取相应的文档管理批量处理信息。 所述请 求解析单元 22具体可包括：
消息体格式识别单元 221 , 用于解析所述文档管理批量处理请求的消息头， 以识别所述文档管理批量处理请求的消息体格式；
批量处理信息获取单元 222,用于根据所述消息体格式解码所述文档管理请 求的消息体， 获取相应的文档管理批量处理信息。 所述批量处理信息获取单元 222具体可包括：
批量增加 /修改处理信息获取子单元 2221， 用于当所述消息体格式识别单元 所识别的消息体格式为文档管理批量增加 /修改请求消息体格式时， 根据所述文 档管理批量增加 /修改请求消息体格式解码所述文档管理请求的消息体， 获取相 应的文档管理批量增加 /修改处理信息；
批量查询处理信息获取子单元 2222, 用于当所述消息体格式识别单元所识 别的消息体格式为文档管理批量查询请求消息体格式时， 根据所述文档管理批 量查询请求消息体格式解码所述文档管理请求的消息体， 获取相应的文档管理 批量查询处理信息；
批量删除处理信息获取子单元 2223, 用于当所述消息体格式识别单元所识 别的消息体格式为文档管理批量删除请求消息体格式时， 根据所述文档管理批 量删除请求消息体格式解码所述文档管理请求的消息体， 获取相应的文档管理 批量删除处理信息； 批量移动处理信息获取子单元 2224, 用于当所述消息体格式识别单元所识 别的消息体格式为文档管理批量移动请求消息体格式时， 根据所述文档管理批 量移动请求消息体格式解码所述文档管理请求的消息体， 获取相应的文档管理 批量移动处理信息。
请求处理单元 23 , 用于根据所述文档管理批量处理信息， 执行相应的文档 管理批量处理操作。 所述请求处理单元具体可包括：
批量增加 /修改请求处理子单元 231 , 用于根据所述文档管理批量增加 /修改 处理信息， 执行文档管理批量增加 /修改处理操作；
批量查询请求处理子单元 232, 用于根据所述文档管理批量查询处理信息， 执行文档管理批量查询处理操作；
批量删除请求处理子单元 233 , 用于根据所述文档管理批量删除处理信息， 执行文档管理批量删除处理操作；
批量移动请求处理子单元 234, 用于根据所述文档管理批量移动处理信息， 执行文档管理批量移动处理操作。
应答处理单元 24, 用于基于文档管理批量处理操作的执行结果信息， 按照 相应的文档管理批量处理操作应答消息格式组装生成文档管理批量处理应答消 息； 向文档管理客户端发送所述文档管理批量处理应答消息。 所述应答处理单 元 24具体可包括：
应答消息生成单元 241 , 用于基于文档管理批量处理操作的执行结果信息， 按照相应的文档管理批量处理操作应答消息格式组装生成文档管理批量处理应 答消息；
应答消息发送单元 242,用于向文档管理客户端发送所述文档管理批量处理 应答消息。
通过上述实施例可以看出， 本发明实施例采用客户端将需要对多个文档或 单个文档下的多个节点的批量处理操作指示， 通过一条文档管理批量处理请求 发送给服务端， 服务端在确定为文档管理批量处理请求时， 获取相应的文档管 理批量处理信息并执行相应的文档管理批量处理操作； 由于客户端只需要发送 一条信令来进行多个文档或单个文档下的多个节点的批量处理操作， 减小了操 作时延， 提高了操作效率， 提高了数据操作的可靠性。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程， 是可以通过计算机程序来指令相关的硬件来完成。 所述的程序可存储于一计算 机可读取存储介质中， 该程序在执行时， 可包括如上述各方法的实施例的流程。 其中， 所述的存储介质可为磁碟、 光盘、 只读存储记忆体（Read-Only Memory, ROM )或随机存储记忆体（Random Access Memory, RAM )等。
以上所述是本发明的优选实施方式， 应当指出， 对于本技术领域的普通技 术人员来说， 在不脱离本发明原理的前提下， 还可以做出若干改进和润饰， 这 些改进和润饰也视为本发明的保护范围。

Claims

权 利 要 求
1、 一种可扩展标记语言文档管理请求方法， 其特征在于， 包括： 接收用户的文档管理批量处理请求指示；
根据所述文档管理批量处理请求指示生成文档管理批量处理请求;
将所述文档管理批量处理请求发送给服务器。
2、 如权利要求 1所述的方法， 其特征在于， 所述文档管理批量处理请求为 文档管理批量增加 /修改请求， 或为文档管理批量查询请求， 或为文档管理批量 删除请求， 或为文档管理批量移动请求。
3、 一种可扩展标记语言文档管理方法， 其特征在于， 包括：
接收文档管理请求；
确定所接收到的文档管理请求为文档管理批量处理请求；
从所述文档管理批量处理请求中获取相应的文档管理批量处理信息； 根据所述文档管理批量处理信息， 执行相应的文档管理批量处理操作。
4、 如权利要求 3所述的方法， 其特征在于， 所述确定文档管理请求为文档 管理批量处理请求的步骤具体为：
根据所述文档管理请求的方法名确定所述文档管理请求为文档管理批量处 理请求。
5、 如权利要求 3或 4所述的方法， 其特征在于， 所述从所述文档管理批量 处理请求中获取相应的文档管理批量处理信息的步骤具体为：
解析所述文档管理批量处理请求的消息头， 以确定所述文档管理批量处理 请求的消息体格式；
根据所述消息体格式解码所述文档管理请求的消息体， 获取相应的文档管 理批量处理信息。
6、 如权利要求 3所述的方法， 其特征在于， 所述根据所述文档管理批量处 理信息， 执行相应的文档管理批量处理操作的步骤之后还包括步骤： 基于文档管理批量处理操作的执行结果信息， 按照相应的文档管理批量处 理操作应答消息格式组装生成文档管理批量处理应答消息， 并向所述文档管理 请求的发送方发送所述文档管理批量处理应答消息。
7、 如权利要求 5所述的方法， 其特征在于， 所述文档管理批量处理请求为 文档管理批量增加 /修改请求， 或为文档管理批量查询请求， 或为文档管理批量 删除请求， 或为文档管理批量移动请求。
8、 一种可扩展标记语言文档管理客户端， 其特征在于， 包括：
用户操作单元， 用于接收用户的批量处理请求指示；
请求生成单元， 用于根据所述文档管理批量处理请求指示生成文档管理批 量处理请求；
请求发送单元， 用于将所述文档管理批量处理请求发送给服务器。
9、 如权利要求 8所述的客户端， 其特征在于， 还包括：
应答消息接收单元， 用于接收来自服务器的批量处理应答消息；
应答消息处理单元， 用于读取所述批量处理应答消息中携带的状态码， 并 根据所述批量处理应答消息的消息头识别是否存在消息体， 若存在， 则根据相 应的批量处理应答消息体格式对消息体进行解码， 获取文档管理批量处理结果 信息。
10、 一种可扩展标记语言文档管理服务器， 其特征在于， 包括：
请求接收单元， 用于接收文档管理请求；
请求解析单元， 用于确定所述文档管理请求为文档管理批量处理请求， 并 从所述文档管理批量处理请求中获取相应的文档管理批量处理信息；
请求处理单元， 用于根据所述文档管理批量处理信息， 执行相应的文档管 理批量处理操作。
11、 如权利要求 10所述的服务器， 其特征在于， 所述请求解析单元包括: 消息体格式识别单元， 用于解析所述文档管理批量处理请求的消息头， 以 识别所述文档管理批量处理请求的消息体格式；
批量处理信息获取单元， 用于根据所述消息体格式解码所述文档管理请求 的消息体， 获取相应的文档管理批量处理信息。
12、 如权利要求 11所述的服务器， 其特征在于， 所述批量处理信息获取单 元包括：
批量增加 /修改处理信息获取子单元， 用于当所述消息体格式识别单元所识 别的消息体格式为文档管理批量增加 /修改请求消息体格式时， 根据所述文档管 理批量增加 /修改请求消息体格式解码所述文档管理请求的消息体， 获取相应的 文档管理批量增加 /修改处理信息；
批量查询处理信息获取子单元， 用于当所述消息体格式识别单元所识别的 消息体格式为文档管理批量查询请求消息体格式时， 根据所述文档管理批量查 询请求消息体格式解码所述文档管理请求的消息体， 获取相应的文档管理批量 查询处理信息；
批量删除处理信息获取子单元， 用于当所述消息体格式识别单元所识别的 消息体格式为文档管理批量删除请求消息体格式时， 根据所述文档管理批量删 除请求消息体格式解码所述文档管理请求的消息体， 获取相应的文档管理批量 删除处理信息；
批量移动处理信息获取子单元， 用于当所述消息体格式识别单元所识别的 消息体格式为文档管理批量移动请求消息体格式时， 根据所述文档管理批量移 动请求消息体格式解码所述文档管理请求的消息体， 获取相应的文档管理批量 移动处理信息。
13、 如权利要求 12所述的服务器， 其特征在于， 所述请求处理单元包括： 批量增加 /修改请求处理子单元， 用于根据所述文档管理批量增加 /修改处理 信息， 执行文档管理批量增加 /修改处理操作；
批量查询请求处理子单元， 用于根据所述文档管理批量查询处理信息， 执 行文档管理批量查询处理操作；
批量删除请求处理子单元， 用于根据所述文档管理批量删除处理信息， 执 行文档管理批量删除处理操作；
批量移动请求处理子单元， 用于根据所述文档管理批量移动处理信息， 执 行文档管理批量移动处理操作。
14、 如权利要求 10至 13任意一项所述的服务器， 其特征在于， 还包括： 应答处理单元， 用于基于文档管理批量处理操作的执行结果信息， 按照相 应的文档管理批量处理操作应答消息格式组装生成文档管理批量处理应答消 息； 向文档管理客户端发送所述文档管理批量处理应答消息。
15、 如权利要求 14所述的服务器， 其特征在于， 所述应答处理单元包括： 应答消息生成单元， 用于基于文档管理批量处理操作的执行结果信息， 按 照相应的文档管理批量处理操作应答消息格式组装生成文档管理批量处理应答 消息；
应答消息发送单元， 用于向文档管理请求发送方发送所述文档管理批量处 理应答消息。
16、 一种可扩展标记语言文档管理系统， 客户端和服务器， 其特征在于， 所述客户端包括：
用户操作单元， 用于接收用户的批量处理请求指示；
请求生成单元， 用于根据所述文档管理批量处理请求指示生成文档管理批 量处理请求；
请求发送单元， 用于将所述文档管理批量处理请求发送给服务器； 所述服务器包括：
请求接收单元， 用于接收文档管理请求；
请求解析单元， 用于确定所述文档管理请求为文档管理批量处理请求， 并 从所述文档管理批量处理请求中获取相应的文档管理批量处理信息；
请求处理单元， 用于根据所述文档管理批量处理信息， 执行相应的文档管 理批量处理操作。
17、 如权利要求 16所述的系统， 其特征在于， 所述服务器还包括: 应答处理单元， 用于基于文档管理批量处理操作的执行结果信息， 按照相 应的文档管理批量处理操作应答消息格式组装生成文档管理批量处理应答消 息； 向文档管理客户端发送所述文档管理批量处理应答消息。
18、 如权利要求 16或 17所述的系统， 其特征在于， 所述客户端还包括： 应答消息接收单元， 用于接收来自服务器的批量处理应答消息；
应答消息处理单元， 用于读取所述批量处理应答消息中携带的状态码， 并 根据所述批量处理应答消息的消息头识别是否存在消息体， 若存在， 则根据相 应的批量处理应答消息体格式对消息体进行解码， 获取文档管理批量处理结果 信息。
PCT/CN2008/073482 2007-12-14 2008-12-12 一种文档管理方法、系统及相关设备 Ceased WO2009076910A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP08861879A EP2209264A4 (en) 2007-12-14 2008-12-12 DOCUMENT MANAGEMENT PROCEDURE, SYSTEM AND APPROPRIATE DEVICE

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200710032635.X 2007-12-14
CN200710032635XA CN101197827B (zh) 2007-12-14 2007-12-14 一种文档管理方法、系统以及相关设备

Publications (1)

Publication Number Publication Date
WO2009076910A1 true WO2009076910A1 (zh) 2009-06-25

Family

ID=39547976

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/073482 Ceased WO2009076910A1 (zh) 2007-12-14 2008-12-12 一种文档管理方法、系统及相关设备

Country Status (3)

Country Link
EP (1) EP2209264A4 (zh)
CN (1) CN101197827B (zh)
WO (1) WO2009076910A1 (zh)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7877484B2 (en) 2004-04-23 2011-01-25 International Business Machines Corporation System and method for bulk processing of semi-structured result streams from multiple resources
CN101197827B (zh) * 2007-12-14 2010-12-08 华为技术有限公司 一种文档管理方法、系统以及相关设备
CN101741877B (zh) * 2008-11-27 2013-01-23 华为技术有限公司 媒体资源的操作方法、系统和设备
CN101808073A (zh) * 2009-02-13 2010-08-18 华为技术有限公司 一种获取节点信息的方法、服务器以及系统
CN102495889A (zh) * 2011-03-22 2012-06-13 苏州阔地网络科技有限公司 一种文件批量处理方法、系统及服务器
WO2013097234A1 (zh) * 2011-12-31 2013-07-04 华为技术有限公司 处理业务的方法和系统
CN102883232B (zh) * 2012-08-29 2015-04-15 四三九九网络股份有限公司 一种swf文件批量添加水印的方法及装置
CN103744665A (zh) * 2013-12-26 2014-04-23 方正国际软件有限公司 漫画播放系统和漫画播放方法
CN105488018A (zh) * 2015-11-24 2016-04-13 魅族科技（中国）有限公司 信息修改方法及终端
CN106846138A (zh) * 2016-12-31 2017-06-13 融捷科技（武汉）有限公司 供应链金融平台文档管理系统
CN106777344A (zh) * 2017-01-16 2017-05-31 郑州云海信息技术有限公司 一种数据库集群的数据节点扩展方法及装置
CN112989288B (zh) * 2021-04-16 2021-09-03 成都飞机工业（集团）有限责任公司 一种批量标定电子文档密级的系统和方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1690969A (zh) * 2004-04-23 2005-11-02 国际商业机器公司 用于批处理来自多种资源的半结构化结果流的系统和方法
US20070074215A1 (en) * 2005-09-27 2007-03-29 Bethea Timothy J Stateless server-side automation of web service requests using dynamically generated web service interfaces
WO2007075234A1 (en) * 2005-12-16 2007-07-05 Microsoft Corporation Xml specification for electronic data interchange (edi)
CN101197827A (zh) * 2007-12-14 2008-06-11 华为技术有限公司 一种文档管理方法、系统以及相关设备

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6766330B1 (en) * 1999-10-19 2004-07-20 International Business Machines Corporation Universal output constructor for XML queries universal output constructor for XML queries
CN100563196C (zh) * 2005-11-25 2009-11-25 华为技术有限公司 通信系统和在通信系统中查询信息的方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1690969A (zh) * 2004-04-23 2005-11-02 国际商业机器公司 用于批处理来自多种资源的半结构化结果流的系统和方法
US20070074215A1 (en) * 2005-09-27 2007-03-29 Bethea Timothy J Stateless server-side automation of web service requests using dynamically generated web service interfaces
WO2007075234A1 (en) * 2005-12-16 2007-07-05 Microsoft Corporation Xml specification for electronic data interchange (edi)
CN101197827A (zh) * 2007-12-14 2008-06-11 华为技术有限公司 一种文档管理方法、系统以及相关设备

Also Published As

Publication number Publication date
EP2209264A4 (en) 2010-10-27
CN101197827A (zh) 2008-06-11
EP2209264A1 (en) 2010-07-21
CN101197827B (zh) 2010-12-08

Similar Documents

Publication Publication Date Title
CN101197827B (zh) 一种文档管理方法、系统以及相关设备
TWI379204B (en) System and method for improved client server communications of email messages
US8583743B1 (en) System and method for message gateway consolidation
US20100198854A1 (en) System and method for searching multiple contact information sources in a network-based address book system
US20040205765A1 (en) System and methods for defining a binding for web-services
US8230003B2 (en) XDM system and method for implementing XML document management function by using position description of XML document
WO2007077227A1 (en) Community messaging system
US20110214051A1 (en) Methods and apparatus to subscribe for change notifications in a document management system
WO2009059541A1 (en) A method and a system for address book processing
KR101331280B1 (ko) Sip 기반의 메시지 서비스 시스템에서 신속 응답 서비스방법
US9391930B2 (en) CPM service provisioning system and method for interworking with non-CPM service
KR101922985B1 (ko) 연락처 정보의 구독을 초대하는 장치 및 방법
WO2009115025A1 (zh) 一种xml文档操作方法及xdms
KR100799559B1 (ko) 단문 메시지 전송 서비스 시스템 및 그 방법
WO2014187397A1 (zh) 多媒体消息的发布方法及装置
Alliance XML Document Management (XDM) Specification
CN101399781B (zh) 一种消息发送方法、系统、消息发送装置及消息服务器
WO2013052365A1 (en) System for contact subscription invitations in a cross-domain converged address book system
US7865504B2 (en) Native file to shared resource locator naming
AU2005258459A1 (en) Message transfer system and message transfer method
WO2010091564A1 (zh) 一种获取节点信息的方法、服务器以及系统
CN101771731B (zh) 获取网络地址本的方法和实现网络地址本的装置
CN102075644B (zh) 融合地址簿中联系视图的实现方法与系统
Saint-Andre et al. Flexible Offline Message Retrieval
WO2009033389A1 (en) Method and equipment for requesting and managing the xml document

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: 08861879

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2008861879

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE