專利名稱：一種xml文檔操作方法及xdms的制作方法
技術領域：
本發(fā)明涉及可擴展標記語言XML技術，尤其涉及一種XML文檔操作方法 及XDMS。
背景技術：
開放移動聯(lián)盟(Open Mobile Alliance, OMA)定義的XML配置訪問協(xié)議 (XML Configuration Access Protocol, XCAP)規(guī)范為角戶提供了可擴,展標記語 言(Extensible Markup Language ， XML)文檔操作信令。這些信令包4舌創(chuàng)建、 修改文檔或節(jié)點(PUT)請求信令、刪除文檔或節(jié)點(DELETE)請求信令、查 找和同步文檔(GET)請求信令，通過這些操作信令完成對XML文檔管理 (XDM)。 OMA定義的XACP規(guī)范是通過版本號(etag)實現(xiàn)文檔版本控制和 增量同步的。在OMA定義的XCAP規(guī)范中，規(guī)定每篇文檔有一個版本號，英文名為etag, 用于描述文檔最新版本信息，由XDM服務器(XDMS)在創(chuàng)建、修改文檔或節(jié) 點時生成，并返回終端。PUT請求信令操作具體為XDMS收到請求后，先按文檔名查找請求的文 檔。若找到此文檔則比較etag，只有etag完全同才視為有權操作，否則視為無 權，返回403 (Forbidden);若未找到文檔則按新增文檔處理。對節(jié)點操作也是 先比較文檔版本號，只有完全相同才繼續(xù)按節(jié)點路徑(用uri描述)分析節(jié)點是 否存在，若不存在按新增節(jié)點處理，否則按替換節(jié)點處理。DELETE請求信令操作具體為XDMS收到請求后，先按文檔名查找請求 的文檔。若找到此文檔則比較etag，只有etag完全相同才視為有權操作，否則 視為無權，返回403 ( Forbidden);若未找到則返回404 (Not Found )。GET請求信令操作具體為XDMS收到請求后，先按文檔名查找請求的文 檔。若找到此文檔則比較etag，只有etag完全相同才返回文檔，否則返回403 (Forbidden);若未找到則返回404 (Not Found )。若GET請求不攜帶etag ，則XDMS不做版本檢查，按默認有權處理。終端登陸時的同步機制終端首先用GET信令從服務端獲取xcap-directory, 服務端返回用戶相關文檔目錄信息，包括統(tǒng)一資源標識符(Unifomj Resource Identifier, uri)、 etag等信息，其中uri由以下幾部分構成AUID+USER—URI+文檔名。由于各人的文檔要在終端緩存的，通過某個終端添加的文檔需要同步到其 它終端后，其它終端才能有這篇文檔，否則登陸時從xcap-directory中獲得文檔 的索引信息后，本地并終端會發(fā)現(xiàn)某些文檔不存在。終端獲得xcap-directory之 后，逐個文檔比較版本號，識別發(fā)生變更的文檔，包括新增的文檔(本地終端 未找到，但xcap-directory有)、修改的文檔(etag發(fā)生變化)和刪除的文檔 (xcap-directory沒有，但本地終端存有)。對于服務端XDMS已經(jīng)刪除的文檔， 本地執(zhí)行物理刪除操作；對于已經(jīng)修改的文檔和新增的文檔，終端重新發(fā)起GET 請求依次獲取文檔。基于OMA定義的版本號機制，文檔版本號是通過XDMS生成的一個隨機 字符串，在新增文檔時便有相應的字符串生成。這些隨機字符串的文檔版本號，在進行文檔k本號比較時只能比較是否相等，不能比較大小。終端在進行版本號的識別后，終端必須先獲取目錄確認哪些文檔發(fā)生變化后，再一篇一篇地獲 取文檔，這種方式下終端與XDMS交互次數(shù)非常多，終端進行文檔操作也帶來 了邏輯復雜性，在真實的商業(yè)環(huán)境(如一個人有200 800個聯(lián)系人文檔和20 30 個分組文檔)中，則會降低用戶的體驗效果。發(fā)明內(nèi)容鑒于上述現(xiàn)有技術所存在的問題，本發(fā)明實施例提供了一種XML文檔操作 方法及XDMS。在引入文檔序列值以后，根據(jù)文檔序列值的更新順序，XDMS 在收到XML操作請求之后，完成對XML文檔的操作過程。為了解決上述技術問題，本發(fā)明實施例提出了一種XML文檔操作方法，該 方法包4舌接收XML文檔操作請求；根據(jù)文檔序列值和XML文檔操作請求完成相，的文檔操作，所述文檔序列 值為按照XML文檔更新順序建立的序列值。相應的，本發(fā)明實施例還提出了一種XDMS,該服務器包括 存儲模塊，用于存儲XML文檔及所對應的文檔序列值，所述文檔序列值為 按照XML文檔更新順序建立的序列值；接收模塊，用于接收XML文檔操作請求；處理模塊，用于根據(jù)所述存儲模塊存儲的所述文檔序列值和接收模塊接收 的XML文檔操作請求完成相應的文檔操作。實施本發(fā)明實施例，通過本發(fā)明實施例中的XML文檔操作方法，在XDMS 中按照XML文檔更新順序為每個XML文檔建立相應的文檔序列值，在收到 XML文檔操作請求時，不用逐個比較XML文檔版本號識別變化的文檔，通過 直接獲取的操作請求中的文檔序列值即可識別該XML文檔序列值以后發(fā)生變 化的文檔并可以一次性返回給用戶終端，減少了終端與XDMS之間的交互過程， 改善了用戶體驗。


圖1是本發(fā)明實施例中XML文檔操作方法的系統(tǒng)圖；圖2是本發(fā)明實施例中處理模塊的結構示意圖；圖3是本發(fā)明實施例中XML文檔操作方法流程圖；圖4是本發(fā)明實施例中基于文檔序列值的PUT請求處理流程圖；圖5是本發(fā)明實施例中基于文檔序列值的DELETE請求處理流程圖；圖6是本發(fā)明實施例中基于文檔序列值的同步(SYNC)請求處理流程圖。
具體實施方式
本發(fā)明實施例提供了 一種XML文檔操作方法及XDMS。在引入文檔序列值 以后，根據(jù)文檔序列值的更新順序，XDMS在收到XML操作請求之后，完成對 XML文檔的操作過程。 '下面結合附圖詳細說明本發(fā)明的優(yōu)選實施例。首先請參閱圖l,圖1示出了本發(fā)明實施中的XML文檔才喿作方法的系統(tǒng)圖， 該系統(tǒng)包括XDMS10和用戶設備(UE) 11，其中UEll用于向XDMSIO發(fā)起 XML文檔操作請求，請求進行相關的XML文檔操作處理,所述UEll可以為 移動終端、PC客戶端、IMS終端等；XDMSIO用于為存儲在XDMSIO中的每一 XML文檔建立相對應的文檔序列值，這些文檔序列值按照文檔更新順序進行 排序，方便用戶的請求操作，通過接收UEll的XML文檔操作請求，并根據(jù)存 儲的文檔序列值對所述UEll發(fā)起的XML文檔操作請求完成相應的文檔操作請 求。XDMS10中設有存儲模塊14、處理模塊13和接收模塊12,其中存儲模 塊14用于存儲XML文檔及所對應的文檔序列值，所述文檔序列值為按照XML 文檔更新順序建立的序列值；接收模塊12用于接收XML文檔操作請求；處理 模塊13用于根據(jù)存儲模塊14存儲的文檔序列值根據(jù)接收模塊12接收的XML 文檔操作請求完成相應的文檔操作。需要說明的是，這里的所述XML文檔操作 類型包括添加文檔、修改文檔、刪除文檔、獲取文檔、同步文檔、添加節(jié)點/ 屬性、刪除節(jié)點/屬性等，這里可以在具體應用時通過相應的命令操作，如PUT 操作、DELETE操作和同步(synchronize, SYNC)操作等完成，這里也不限于 所述幾種操作處理方式和命令方式。相應的，圖2示出了本發(fā)明實施例中處理 模塊13的結構示意圖，其中處理模塊13還包括了第一判斷單元201、刪除單 元202、生成單元203、同步單元205和第二判斷單元204，其中第一判斷單 元201用于判斷所述XML文檔操作請求中的文檔序列值和存儲的文檔序列值是 否相同；刪除單元202用于第一判斷單元201判斷文檔序列值相同和所述XML 文檔操作請求類型為刪除文檔請求時，對相應的XML文檔刪除操作；生成單元 203用于第一判斷單元201判斷文檔序列值相同和所述XML文檔梯:作請求類型 為修改文檔請求或刪除文檔節(jié)點請求時、或所述XML文檔操:作請求類型為添加 文檔請求或添加文檔節(jié)點/屬性請求時，按照XML文檔更新順序為更新或增加 的XML文檔生成相應的文檔序列值；第二判斷單元204用于根據(jù)文檔序列值判 斷XML文檔操作請求中所需要同步的XML文檔范圍；同步單元205用于根據(jù) 第二判斷單元判斷的XML文檔范圍對需要同步的XML文檔進行文檔同步操作。本發(fā)明實施例提出了 一種基于遞增或遞減的文檔序列值進行文檔版本控制 和文檔同步的機制，由UE、.XDMS和文檔序列生成器配合實現(xiàn)，該文檔序列生 成器即為XDMS中的共理4莫塊13。這個遞增或遞減的文檔序列值可以是最新的 時間戳，也可以遞增或遞減的數(shù)字，本發(fā)明實施例中用timemark來描述文檔序 列值，以區(qū)別于etag。同一用戶同一業(yè)務的文檔，文檔序列值最好由同一文檔序列生成器生成， 這樣可以保證同一用戶同一業(yè)務的文檔能通過序列值的大小識別哪些是最新生成或變更的文檔，這里所說的業(yè)務，是業(yè)務標識(這里用AUID進行描述)的 概念，包括但不限于OMA定義的業(yè)務，如resource-lists (分組)、 org.openmobilealliance.user-profile (個人"f言,包')、org.openmobilealliance.groups (群 組)等，也可以是自定義業(yè)務，如contact-profile (聯(lián)系人)。文檔序列生成器是 一個文檔序列值生成^t塊，當通過凄t據(jù)庫的序列生成方法生成文檔序列值時， XDMS中的數(shù)據(jù)庫系統(tǒng)為文檔序列生成器；當通過時間戳作為文檔序列值時， XDMS中的操作系統(tǒng)的時鐘序列為文檔序列生成器。同一用戶同一業(yè)務的文檔 一Jl殳由同一個文檔序列生成器生成文檔序列值，可以避免在文檔變更識別方面值，只要不影響同一用戶的文檔變更先后關系識別，也是允許的。在請求操作XML文檔操作過程中，用戶需要開通相應的請求操作業(yè)務才^L 為有權才喿作，否則服務器會拒絕此次請求操作，只有在用戶開通了相應的文檔 操作業(yè)務時，才為合法請求。下面將以用戶有4又操作的情況下進行描述，即用 戶開通了所要請求的操作請求時，圖3示出了本發(fā)明實施例中的XML文檔才喿作 方法流程圖，步驟如下步驟.S301:接收XML文檔^J喿作請求；在XDMS中為存儲的XML文檔按照文檔更新順序建立所對應的文檔序列 值，并將所述文檔序列值存儲，其主要根據(jù)時間序列或數(shù)據(jù)序列的更新順序為 存儲的XML文檔建立文檔序列值。所述XML文檔操作請求類型包括添加文檔請求、修改文檔請求、刪除文檔 請求、添加節(jié)點/屬性請求、刪除節(jié)點/屬性請求和同步文檔請求等，這里也不限 于這幾種請求操作，本發(fā)明實施例主要PUT操作、DELETE操作和SYNC操作 等方式實現(xiàn)。步驟S302:根據(jù)文檔序列值和XML文檔操作請求完成所請求的文檔操:作， 所述文檔序列值為按照XML文檔更新順序建立的序列值。所述XML文檔操作請求為添加文檔請求、或添加文檔節(jié)點/屬性請求時， 根據(jù)文檔序列值更新順序為新添加的XML文檔生成相應的文檔序列值。需要說所述XML文檔操作請求類型包括修改文檔請求、刪除文檔請求、刪除文檔 節(jié)點/屬性請求、替換文檔節(jié)點/屬在時，所述XML文檔操作請求中包括文檔序 列值；判斷所述XML文檔操作請求中的文檔序列值和存儲的文檔序列值是否相 同；如果所述XML文檔操作請求中的文檔序列值和存儲的文檔序列值相比4交相 同，則根據(jù)文檔序列值完成所述XML文檔操作。所述XML文檔操作請求類型 為修改文檔請求、刪除文檔節(jié)點/屬性請求和替換文檔節(jié)點/屬性時，按照XML 文檔更新順序為更新的XML文檔生成相應的文檔序列值。所述XML文檔才喿作 請求類型為刪除文檔請求時，根據(jù)文檔序列值刪除所需要刪除的XML文檔。對 于已經(jīng)刪除的文檔，無法通過本發(fā)明實施例中的同步方法獲得，但可以通過獲 取Xcap-Directory,再判斷文檔是否存在，若服務端返回的目錄不存在，則視為 文檔已刪除，終端可以執(zhí)行本地刪除。所述XML文檔操作請求為同步文檔請求時，所述XML文檔操作請求中包 括文檔序列值；根據(jù)文檔序列值判斷XML文檔操作請求中所需要同步的XML 文檔范圍；在判斷完所需要進行同步的XML文檔范圍后，對需要同步的XML 文檔進行文檔同步操作。所述需要同步的XML文檔范圍為基于文檔序列值的所 有更新的XML文檔或滿足同步請求中給定文檔序列值取值范圍的所有XML文 檔。當有多個基于同步請求中文檔序列值的更新XML文檔需要進行同步操作， 將所述多個文檔按照文檔序列值一次或分批的進行同步操作。需要說明的是， 本發(fā)明實施例中所述XML文檔同步操作是通過同步信令SYNC命令操作完成 的，同步信令包括需要同步的文檔內(nèi)容、文檔名、文檔序列值和業(yè)務標識。下面來詳細說明基于文檔序列值的PUT請求處理流程過程，具體流程圖如 圖4所示，步驟如下步驟S401: UE向XDMX發(fā)起PUT請求；步驟S402:若文檔存在，則比較文檔序列值，如果文檔序列值不同則進行步驟 S403a,如果文檔序列值相同則進行步驟S403;步驟S403a:如果文檔序列值不同，則返回403 (Forbidderi);步驟S403: XDMS向文檔序列生成器申請文檔序列值；步驟S404:文檔序列生成器向XDMS返回申請的文檔序列值；這里需要說明的是，步驟S403和步驟S404是文檔序列值的生成過程，其4姿照一定的生成^見則，如遞增生成相應的序列值或遞減生成相應的序列值，如果存在最新文檔序列值200712031206時，那么生成的下個文檔序列值應該為 200712031207;如果時按照時間戳生成，則自動根舉時間戳的增加即可生成對 應于時間戳的文檔序列值。這里可以在生成新的XML文，當時建立所對應的文檔 序列值。步驟S405:創(chuàng)建或^f，務改文檔；在創(chuàng)建或修改XML文檔后，每個文檔即可有相同的文檔序列值。 步驟S406: XDMS向UE返回應答消息。所述應答消息中包含了新的文檔信息以及新的文檔信息相同的文檔序列 值，所述文檔序列值可以為下次XML文檔操:作時提供基準。 -基于文檔序列值的DELETE請求處理流程過程的具體流程圖如圖5所示， 步驟如下步驟S501: UE向XDMS發(fā)起PUT請求；步驟S5()2:若文檔存在，則比較文檔序列值，如果文檔序列值不同則進4亍 步驟S503，如果文檔序列值相同則進行步驟S504;步驟S503:如果文檔序列值不同，則返回403 (Forbidden);步驟S504:刪除文檔；步驟S505: XDMS。向UE返回應答消息。在引入了文檔序列值機制后，PUT、 DELETE、 GET等OMAXCAP信令的 應答消息頭中，應增加文檔序列值信息，用timemark進行描述。如DELETE應 答消息HTTP/1.1 200 OK aSe而:XDM-serv/OMAl .0Date:Wed, 19 Dec 2007 0鋒:19 GMTEtag:"wMm8L"timemark: "20071001082030"Content-Length: 0Connection: close如果是批量修改或獲取文檔，則每篇文檔的文檔序列值出現(xiàn)在應答消息體 中。例如批量修改文檔返回的應答消息體中攜帶文檔序列值<file name="index"〉 <result〉200</result> <err-info/> <etag〉nSNji</etag><timemark〉20071219110714</timemark〉 </file>其中，每個file對應一篇文檔，timemark則是本發(fā)明所說的文檔序列值。 批量獲取文檔時，文檔序列值可以和文檔名、etag—起返回，如采用以下形式<file name="s—white" etag="iH9dv" timemark="20071219102657"〉通過文檔序列值，終端登陸時可以按文檔序列值范圍獲取文檔。"遞增"或 "遞減"是XDMS提供的序列生成方式，在增量同步時也據(jù)此識別增量范圍。 例如，文檔序列值自某個值起以遞減方式生成時，XDMS會認為序列值越小文 檔越新一一最近發(fā)生變化。通常，文檔序列值按遞增方式生成，這比較符合習 慣。按文檔序列值同步文檔時，XDMS識別變更的所有文檔，在一次請求應 答中返回該序列值起所有發(fā)生變化的文檔。文檔序列值也可用于版本控制，只有請求中的文檔序列值與XDMS中的文 檔序列值完全相同(即相等)，才視為有權操作，否則視為無權操作，返回403 (Forbidden)。在版本控制方面，文檔序列值與etag的作用完全等價。為避免與OMA定義的GET信令沖突，本發(fā)明實施例提供了一種新的同步 信令，取名為SYNC。圖6示出了本發(fā)明實施例中的基于文檔序列值的SYNC 請求處理流程過程，具體步驟如下；步驟S601: UE發(fā)起SYNC請求，帶鑒權信息；步驟S602:識別所需要進行同步的文檔；步驟S603: —次或分批返回所需要的文檔。在實現(xiàn)同步過程中，可以根據(jù)文檔數(shù)量的多少批量返回所需要進行同步的 文檔，每批文檔可以包含有多個需要進行同步的文檔，不需要每個文檔進行交 互。如果文檔少，則一次性同步所需進行的多個文檔；如果文檔^t量多，則可 以分多批次同步所需要進行的文檔，避免了將所要文檔都封裝在一個大的XML文檔中。按照批量進行文檔同步時，每次返回文檔時可以給出下一批文檔的序列基準值，UE根據(jù)這個發(fā)起獲取下一批文檔的請求。例如，文檔序列值為210 至800時，每次返回50篇文檔，首次請求可以乂人21開始，則第一次返回的下 一批序列基準值是260，則UE下次獲取文檔可以從260起，服務器返回未找到 文檔為止。當文檔同步請求給定文檔序列值起始范圍時，當文檔序列值為增序生成時， 所述滿足條件的文檔集合指服務器端文檔序列值大于等于文檔同步請求中同一 業(yè)務的文檔序列值起始值，但小于文檔同步請求中同 一業(yè)務的文檔序列值結束 值；當文檔序列值為降序生成時，所述滿足條件的文檔集合指服務端文檔序列 值小于等于文檔同步請求中同一業(yè)務的文檔序列值起始值，但大于文檔同步請 求中同一業(yè)務的文檔序列值結束值。當文檔同步請求僅給定文檔序列值起始值時，當文檔序列值為增序生成時， 所述滿足條件的文檔集合指服務端文檔序列值不小于文檔同步請求中同一業(yè)務 的文檔序列值；當文檔序列值為降序生成時，所述滿足條件的文檔集合指服務 端文檔序列值不大于文檔同步請求中同 一業(yè)務的文檔序列值。由于通過文檔序列值進行文檔刪除后在服務端不再保留，通過文檔序列值 進行增量同步時，除非終端給定的文檔序列值為系統(tǒng)預置的序列初試值，否則 終端不能g據(jù)服務端返回的文檔知道哪些文檔已被物理刪除。需要說明的是，xcap-directory得到文檔目錄并不沖突，事實上終端仍然可以通過獲取 xcap-directory獲得文檔目錄，并通過比較文檔列表獲知哪些文檔已被鄰'J除。對 于新增和修改過的文檔同步，釆用本發(fā)明所述文檔序列值的方法可以獲得更高 的效率。下面將詳細描述SYNC信令格式，表1為SYNC信令定義的表格圖，包括 請求消息和應答消息，其中請求消息包括請求行、請求消息頭和請求消息體，其中請求行包括請求 的業(yè)務、發(fā)起請求的用戶號碼、請求的業(yè)務內(nèi)容、請求的統(tǒng)一資源標識符；應答消息包括應答狀態(tài)行、應答消息頭和應答消息體，其中應答狀態(tài)行 包括返回碼類型。 <MethodtokenXCAP請求方法，取值SYNCRequest-URIHTTP而指定請求操作的XCAP資源。HTTP-VersionHTTP版本，取值HTTP/U表1請求行SYNC請求由Request-URI構成XCAP Root + AUID + "users" + XUI。完整的同步請求行如下"SYNC http:〃xcap.example.com/resource隱lists/users/sip: 123324@huawei.com HTTP/U"。其中，"resource-lists"表示分組業(yè)務，如果同步多個業(yè)務可以用特殊符號替 代，如"00",表示同步的業(yè)務在請求消息體中定義，"123324"表示發(fā)起請求 的用戶號碼，"sip:"表示這是一個sipuri, "huawei.com"為用戶'123324，歸 屬的XDMSi或名。請求消息頭SYNC請求消息頭才各式如下Content-type: application/sync+xmlContent-Length:(…)其中application/sync+xml是SYNC請求的消息體格式。請求消息體SYNC請求消息體格式< xml version="1.0" encoding="UTF-8" > <xs:schema xmlns:xs="http:〃www.w3.org/2001/XMLSchema" xmlns="com:huawei:sync" targetNamespace="com:huawei:sync" elementFormDefault="qualified"><xs:element name="list"> ' <xs: complexType> <xs:sequence>〈xs:element name="auid" type="auidType" maxOccurs="unbounded"/〉</xs:scqucncc>〈xs:attribute name="timemark" type="xs:string" use="optional7> </xs:complexTypc></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"/> </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" type="xs:string" use="optional"/> </xs: complexType〉 </xs:schema〉需要說明的是，這里的"com:huawei:sync"為SYNC請求消息體的命名空間 (namespace); timemark為文檔序列4直，list的timemark屬'f生表示所有業(yè)務的文 檔序列值必須晚于給定的值，auid中的timemark屬性表示當前auid對應的業(yè)務 的文檔序列值必須晚于給定的值，file中的timemark元素表示文檔的序列值必須 等于給定的值一一等價于etag;上述格式中timemark均是可選，這就帶來了靈 活性，具體講內(nèi)層的timemark存在時，序列值需要按等于處理，.list和auid 中的timemark同時存在時，取最近序列值作為基準，如1比2小，序列值為遞 增方式時，取2,反之取l;上述格式還給出了同步的范圍表達方式，越到內(nèi)層 范圍越小，是個逐級收斂的過程；auidType中name為auid的名字，如 name="resource-lists"; fileType中name為文檔名，可以用"*"表示獲取所有文 檔；auid下既指定具體文檔名又指定文檔名為、"時，則取該用戶auid下的所有 文檔。應答4犬態(tài)4亍格式HTTP-Version + Status-Code + Reason-Phrase 示例如下HTTP-Version: HTTP/1.1 Status-Code: 200Reason-Phrase: OK其中SYNC應答狀態(tài)行的Status-Code取自OMA定義的返回碼類型，如 200 (成功)、500 (內(nèi)部錯誤)、404 (未找到)。應答消息頭Content-Type: application/sync-result+xml Content-Length:(...)其中application/sync-result+xml表示SYNC信令應答消息體格式。應答消息體SYNC應答消息體格式(Schema):< xml version="1.0" encoding="UTF-8" > <xs:schema xmlns:xs="http:〃www.w3 .org/2001/XMLSchema" xmlns="com:huawei:sync-result" targetNamespace="com:huawei:sync-result" elementFormDefault="qualified"> <xs:element name="list"〉 <xs: complexType〉 <xs:scqucnc6>〈xs:element name="auid" type="auidType" maxOccurs="unbounded"/></xs:scqucncc〉〈xs:attribute name="timemark" type="xs:string" use="required"/〉e </xs: complexType> </xs:element> 〈xs:element name="file"> <xs: complexType> <xs:sequcnce〉<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded'V> </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="optional7> </xs: complexType> </xs:element〉<xs:complexType name="auidType"> <xs:sequcnce><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="required7〉 <xs:attribute name="timemark" type="xs:string" use="optional'V></xs: corrfJ)lexType> </xs:schema>其中"com:huawei:sync-result"為SYNC應答消息體命名空間(NameSpace); SYNC應答消息體消息體分list、 auid和file三級，list為才艮節(jié)點，auid描述業(yè)務， file描述文檔；list中的timemark屬性為下次同步所有業(yè)務的基準值，如當前系 統(tǒng)時間；auid節(jié)點name為auid名字，ctype為auid對應的schema (即消息體 格式)，timemark為業(yè)務對應的下次同步基準序列值，如當前系統(tǒng)時間；file節(jié) 點name為文檔名，etag為文檔版本號，timemark表示文檔最新變更時間(含 新增)；應答消息中auid的timemark為空時表示業(yè)務下次同步的序列值參照list 中的timemark 。下面將描述一個完整的SYNC請求消息和應答消息，具體描述如下 SYNC請求消息SYNC http:〃www.example.com/00/users/l3500000000 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—black7〉<file name="s—white7〉 </auid〉<auid name="contact-profile" timemark="20071212123000"><file name="*7></auid></list>需要說明的是，SYNC的Request-uri中AUID是"OO ",表示用戶13500000000 要求同步多個業(yè)務的文檔，業(yè)務信息從請求消息體中獲取。用戶13500000000 請求同步"resource-lists"下的s—black和s—white,以及"contact-profile"下的所 有文檔，對s—black和s—white的要求是文檔序列值大于等于"20071212121212", 對"contact-profile"的文檔要求是文檔序列值大于等于"20071212123000"。SYNC應答消息HTTP/U 200 OKServer:XDM畫serv/OMAl .0Date:Wed， 19 Dec 2007 06:15:51 GMTContent-Length:2041Connection: close<ljst xmlns="com:huawei:sync-result" timemark="20080101102010"〉 <auid name="resource-lists" ctype="application/resource-lists+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+xmr><file name="m—12344" etag="PGzSU" timemark="20071219141456"><contact-profiles xmlns="com:huawei:xml:xdm:contact-profile"><contact-profile uri="http:〃www.altova.com"><display-name xml:lang="en-us">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-profiles xmlns="com:huawei:xml:xdm:contact-profile"> <contact-profile uri="sip: 1380000000 l@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作為下次同步數(shù)據(jù)的基準，各一致。綜上所述，在對XML文檔引入文檔序列值以后，終端不必先獲取 xcap-directory進行逐個比較文檔版本號，識別發(fā)生變化的XML文檔，而是直接 告訴XDMS文檔同步的基準序列值，由XDMS識別自該序列值以后發(fā)生變化的 文檔并一次性返回終端。這一變化簡化了終端同步文檔的處理邏輯，以及終端 與XDMS之間的交互過程，也減少了終端與XDMS之間交互的次數(shù)，從而減少 了文檔同步的時間，改善了用戶體驗。除了文檔同。步功能之外，文檔序列值可 以作為OMAetag的替代方案，即按文檔序列值是否相同作為操作權限判斷的依 據(jù)，在實現(xiàn)了操作權限判斷之后，對于更新文檔的請求，如添加/修改操作等時， 可以為更新文檔生成相應的文檔序列值，通過所述文檔序列值能夠反應出XML 文檔的更新狀態(tài)，以便服務器更好的進行XML文檔操作。以上所揭露的僅為本發(fā)明實施例中的一些較佳實施例而已，當然不能以此 來限定本發(fā)明之權利范圍，因此依本發(fā)明權利要求所作的等同變化，仍屬本發(fā) 明所涵蓋的范圍。
權利要求
1、一種XML文檔操作方法，其特征在于，該方法包括接收XML文檔操作請求；根據(jù)文檔序列值和XML文檔操作請求完成所請求的文檔操作，所述文檔序列值為按照XML文檔更新順序建立的序列值。
2、 如權利要求1所述的XML文檔操作方法，其特征在于，所述方法還包 括為存儲的XML文檔按照文檔更新順序建立所對應的文檔序列值，并將所述 文檔序列值存儲。
3、 如權利要求2所述的XML文檔操作方法，其特征在于，所述為存儲的 XML文檔按照文檔更新順序建立所對應的文檔序列值步驟具體為為存儲的XML文檔按照時間順序或數(shù)據(jù)序列的更新順序建立所對應的文 檔序列值。
4、 如權利要求3所述的XML文檔4喿作方法，其特征在于，所述XML文 檔操作請求類型包括添加文檔請求、或修改文檔請求、或刪除文檔請求、或添 加節(jié)點/屬性請求、或刪除節(jié)點/屬性請求、或查找文檔請求，或同步文檔請求。
5、 如權利要求4所述的XML文檔操作方法，其特征在于，所述XML文 檔操作請求為添加文檔請求、或添加文檔節(jié)點/屬性請求時，所述根據(jù)文檔序列 值和XML文檔操作請求完成所請求的文檔操作步驟具體為根據(jù)XML文檔操作請求生成新的XML文檔，并根據(jù)文檔序列值更新順序 為所述新的XML文檔生成相應的文檔序列值。
6、 如權利要求4所述的XML文檔操作方法，其特征在于，所述XML文 檔操作請求類型為修改文檔請求、或刪除文檔請求、或刪除文檔節(jié)點/屬性請求、 或替換文檔節(jié)點/屬性時，所述XML文檔操作請求中包括文檔序列值；所述根據(jù)文檔序列值和XML文檔操作請求完成所請求的文檔操作步驟具體為判斷所述XML文檔操作請求中的文檔序列值和存儲的文檔序列值是否相同；如果所述XML文檔操:作請求中的文檔序列值和存儲的文檔序列值相同，則 根據(jù)文檔序列值完成所述XML文檔操作。
7、 如權利要求6所述的XML文檔操作方法，其特征在于，所述XML文檔操作請求類型為修改文檔請求、或刪除文檔節(jié)點/屬性請求、 或替換文檔節(jié)點/屬性時，所述根據(jù)文檔序列值完成所述XML文檔操作具體為
8、 如權利要求4所述的XML文檔操作方法，其特征在于，所述XML文 檔操:作請求為同步文檔請求時，所述XML文檔才喿作請求中包括文檔序列值；所述根據(jù)文檔序列值和XML文檔操作請求完成所請求的文檔操作步驟具 體為根據(jù)文檔序列值判斷XML文檔操作請求中所需要同步的XML文檔范圍； 對需要同步的XML文檔進行文檔同步操作。
9、 如權利要求8所述的XML文檔操作方法，其特征在于， 所述需要同步的XML文檔范圍為基于文檔序列值的所有更新的XML文檔或滿足同步請求中給定文檔序列值取值范圍的所有XML文檔。
10、 如權利要求9所述的XML文檔操作方法，其特征在于，所述對需要同 步的XML文檔進行文檔同步操作具體為當有多個基于同步請求中文檔序列值的更新XML文檔需要進行同步操作， 將所述多個文檔按照文檔序列值更新順序一次將多個文檔進行同步操作。
11、 一種XDMS，其特征在于，該服務器包括存儲模塊，用于存儲XML文檔及所對應的文檔序列值，所述文檔序列值為 按照XML文檔更新順序建立的序列值；接收模塊，用于接收XML文檔操作請求；處理模塊，用于根據(jù)所述存儲模塊存儲的所述文檔序列值和接收模塊接收 的XML文檔纟喿作請求完成相應的文檔操作。
12、如權利要求11所述XDMS,其特征在于，所述處理模塊包括第 一判斷單元，用于判斷所述XML文檔操作請求中的文檔序列值和存儲的文檔序列值是否相同；刪除單元，用于當所述第 一判斷單元判斷相同和所述XML文檔操作請求類型為刪除文檔請求時，刪除相應的XML文檔。
13、如權利要求12所述的XDMS,其特征在于，所述處理模塊還包括 生成單元，用于當所述第 一判斷單元判斷相同和所述XML文檔操作請求類 型為修改文檔請求或刪除文檔節(jié)點請求時、或所述XML文檔操作請求類型為添 加文檔請求或添加文檔節(jié)點/屬性請求時，按照XML文檔更新順序為更新或增 加的XML文檔生成相應的文檔序列值。
14、如權利要求13所述的XDMS，其特征在于，所述處理模塊還包括 第二判斷單元，用于根據(jù)文檔序列值判斷XML文檔操:作請求中所需要同步 的XML文檔范圍；同步單元，用于根據(jù)第二判斷單元判斷的XML文檔范圍對需要同步的XML 文檔進行文檔同步操作。
全文摘要
本發(fā)明實施例公開了一種XML文檔操作方法，該方法包括以下步驟接收XML文檔操作請求；根據(jù)文檔序列值和XML文檔操作請求完成所請求的文檔操作，所述文檔序列值為按照XML文檔更新順序建立的序列值。本發(fā)明實施例還公開了一種XDMS，通過本發(fā)明實施例提供的方法和XDMS，減少了終端與XDMS之間的交互過程，從而減少了終端與XDMS交互的時間，改善了用戶體驗。
文檔編號H04L29/06GK101256572SQ20081002693
公開日2008年9月3日 申請日期2008年3月21日 優(yōu)先權日2008年3月21日
發(fā)明者寧 丁, 伊志權, 斌 劉, 盧劍鋒, 海 向 申請人:華為技術有限公司