使用資源有限的設備處理電子表單的方法和設備的制作方法

專利名稱：使用資源有限的設備處理電子表單的方法和設備的制作方法
技術領域：
本發明一般而言涉及數據處理。具體來說，本發明涉及在諸如因特網的計算機網絡上處理電子表單的基于XML的可伸縮表單引擎。
表單，無論是紙做的還是網頁，表示了結構化的數據交流。在因特網環境中，表單是使用戶能夠與網絡服務器交互的一種簡單方式。一個人有許多理由選擇使用表單。最簡單的表單通常被創建用以從用戶那里征求反饋。更復雜的表單允許用戶核對他們的銀行帳戶余額，購買飛機票，和檢查它們的電子郵件。在網絡上，表單已經成為用于搜索引擎，投票，調查，電子商務，甚至還有在線申請的尋常事情。
目前，基于表單的XHTML(extensible hypertext markup language，可擴展超文本標記語言)被用于獲取用戶的輸入。通過使用XHTML表單，用戶可以訪問網頁，向該頁添加信息，并把該頁提交到網絡服務器。一個電子商務方面的非常簡單的例子是在用戶為了從購物列表中訂購物品而填寫XHTML表單的時候。


圖1舉例說明了一個允許客戶數據被發送到服務器的示范XHTML表單的XHTML代碼。輸入元素10-12收集來自用戶的文本表單中的數據。該數據然后被表單元素(未畫出)指示發送到URL(Uniform ResourceLocator，統一資源定位)以便被處理。該URL指向準備處理該數據的服務器應用程序。例如圖1中顯示出的那樣，一個使用XHTML表單來在網絡上定制物品的缺點是越來越復雜的事務(transaction)開始超出XHTML表單的局限。隨著網絡上電子商務的增長，提供更復雜的方式來交換數據的需要也同樣增長。例如，公司A可能需要向公司B下達一個購買訂單。然而，公司A可能想要在交易中加入一些條件。沒有通用的語言，這個過程變得困難并且需要復雜的編程。除了數據交流上的局限，關于現在的XHTML表單還有其他的擔心，例如，達不到將數據和表示分離。現在的表單控件將表示與相關的數據緊密的結合在了一起。盡管對于簡單的表單這也許不會引起嚴重的問題，例如圖1中的那個，但當需要復雜的表單來為較大的公司推動電子商務的時候，它就會變得麻煩。
因為表單繼續成為網絡的重要部分，表現為許多網站使用的交互性的首要工具，網絡應用程序和電子商務解決方案已經引發了關于具有更豐富交互性的更好的網絡表單的需求。為了處理這個需求，W3C(worldwideweb consortium，世界網絡協會)已經提出一種新的表單的三部分標準，被稱為XForms1.0，它基于XML(extensible markup language，可擴展標記語言)。XForms1.0允許為了在XForms處理器和遠程實體之間在線交互創建新的與平臺無關的標記語言。XForms是XHTML表單的繼任者，并且從XHTML表單多年的實踐經驗吸取的教訓中獲益。關于XForms的更多細節可以在發布于http//www.w3.org/MarkUp/Forms的“XForms-下一代網絡表單(XForms-the Next Generation of WebForms)”(W3C5/10/2002)，和發布在www.w3.org/TR/xforms的“XForms1.0”(W3CWorking Draft，2002年1月18日)上找到，他們都作為參考在此引入。XForms代表了網絡上的下一代表單。為了使用戶克服前面提到的根據表單的XHTML的擔心，Xforms的一個主要目的是把數據從數據表示中分離出來。XForms將可以把用戶接口從數據和邏輯中分離出來，理論上用戶被允許在計算機桌面、個人數字助理(PDA，personal digitalassistant)、或手機上完成同樣的表單，如果這些設備具有足夠的內存和處理能力。
XForms將能夠提供更豐富的并且與表示無關的處理交互網絡事務的方式。通過把傳統的XHTML表單分為三部分——數據模型，實例數據，和用戶界面(表示)--XForms通過將表單的數據和邏輯從它的表示中分離出來克服了基于表單的XHTML前面陳述的局限。在這種方式中，表單數據可以獨立于最終用戶如何與應用程序交互來被定義。這允許了靈活的表示選擇。
圖2一般地舉例說明了XForms的表示從數據和邏輯的分離，并更具體的舉例說明了被參考為XForms數據模型22的，定義了單個模型項目(model item)，約束(constraint)和其他XForms運行時方面的單獨的設備無關的XML不可見表單——如何能夠工作在多種標準或私有的用戶接口上，諸如XForms用戶接口24，可擴展超文本標記語言(XHTML，extensible hypertext markup language)接口26，無線標記語言(WML，wireless markup language)接口27和其他私有接口28。
一種基于推薦的XForms1.0的XForms引擎為促進XML文檔的處理服務并且被配置成與全部推薦的XForms1.0兼容，而且因此需要相關的大型軟件組件。傳統XForms引擎的一個缺點是，給定了它們的大小，它們不能很好的適合在特性為具有有限的處理能力和內存的“精簡型”設備上使用。例如，這種精簡型設備可能包括個人數字助理(PDAs，personaldigital assistants)，手機，置頂盒或者其他因特網可用的“精簡型”處理設備。
因此，一種需求為基于W3C XForms1.0子集的XForms引擎而存在，那就是適合在“精簡型”設備使用能夠克服那種設備的處理和內存局限的特性。
本發明通過提供一種適合在“精簡型”設備，也就是具有有限處理和內存約束的設備中使用的可伸縮的XForms引擎，解決了一個或多個上面確定的現有技術中的問題。該可伸縮的XForms引擎，在此稱為微XForms引擎，在它并入了的W3C(worldwide web consortium，世界網絡協會)XForms1.0的指定的子集的意義上是可擴展的，該指定的子集適用于精簡型設備的處理和內存的約束。
依照該發明的一個方面，基于XML的電子表單通過將本發明的微XForms引擎合并在該精簡型設備上的有限的內存中，被制作成適應由所謂的具有有限處理和存儲能力的“精簡型“設備的處理。
依照本發明處理電子表單的一種方法包括如下步驟使用基于全部XFroms1.0的指定子集的XForms引擎處理可擴展標記語言(XML，extensible mark-up language)文檔(也就是電子表單)；和利用處理步驟的結果來輸出合法的XForms實例文檔(也就是合法的完整的電子表單)。
一種實現本發明的系統包括至少一個網絡服務器(例如電子貿易商)來與一個或多個在“精簡型“設備內存中合并了微XForms引擎的“精簡型”設備通信，來處理接收到的基于XML的電子表單。
有利地是，本發明允許內存受約束的“精簡型“設備和其他類型的內存受約束的因特網可用的設備通過實現推薦的Xform1.0工作標準的為特別的精簡型設備的內存能力而擴展的子集來處理基于XML的電子表單。可伸縮性是依照精簡型設備的內存和其他約束來實現的，其可以使該精簡型設備通過有效率的方式來處理基于XML的電子表單。本發明可適合在將來的XForms標準版本上使用也是本發明的預期之一。
因為本發明的微XForms引擎來源于推薦的XForms1.0的子集，它是基于XML的，它仍保留了XML帶來的可擴展的好處。那就是，該微XForms引擎允許電子表單生成的表示方面與該表單的數據和邏輯中分離開來，進而提供了數據的無關性。同樣的，微XForms引擎適合于在種類寬廣的用戶平臺上使用，包括“精簡型“設備，因為數據模型沒有被與它的表示相綁定。例如，電子表單可以在PC上通過HTML用戶接口來顯示和填充，同時同樣的表單可在以包括具有WML用戶接口的手機或含有支持語音識別或手寫識別的用戶接口的精簡型設備在內的類型寬廣的”精簡型“設備來呈現和填充。無論使用哪種平臺來顯示電子表單，該微XForms引擎提供了設備無關性從而確保基礎(underlying)XML應用程序可以依賴來自表單的有效的輸入而不管使用的用戶接口。本質上，本發明的微XForms引擎利用基于基礎XML的應用程序和表示(也就是用戶界面)之間的解耦合并且使用基于XML的應用程序的子集以使精簡型系統可以處理XForm。
本發明被進一步通過例子的方式和參考附圖來解釋，其中，圖1依照現有技術說明了用于顯示允許用戶數據被發送到服務器的XHTML表單的XHTML代碼；圖2依照現有技術的實施例說明了基于XML的電子表單處理系統中表單從表示中的分離；圖3顯示了本發明的微XForms引擎可以被實現的處理設備的例子；圖4顯示了基于因特網的通信系統的例子，其中，本發明的微XForms引擎可以被實現；圖5a顯示了包含一些基于完整的XML的標準的XForms棧，依照現有技術來構造；圖5b顯示了包含一些基于簡化的XML的標準的XForms棧，依照本發明的理論來構造；圖6說明了在因特網網絡環境中實現的本發明的微XForms引擎；圖7是數據流表，說明了與在精簡型設備中接收電子表單建立XForms模型相關聯的數據流；圖8是XPath綁定如何被實現以用于將UI(user interface，用戶接口)輸入字段綁定到XPath表達式的說明性的例子。
圖3顯示了處理設備30的例子，其中，本發明微XForms引擎可以被實現。設備30包括在一個或多個系統總線的集合35上的至少一部分上通信的處理器32和內存34。同樣也利用了一個或多個系統總線的集合35上的至少一部分的是顯示器36和一個或多個輸入/輸出(I/O，input/output)設備38。處理設備30可以代表“精簡型“設備，該“精簡型“設備被配置來促進在使用諸如IP(Internet Protocol，因特網協議)的眾所周知的協議的無線或有線網絡或兩者的綜合上的電子商務活動。例如，這樣的精簡型設備可以包括無線電話，個人數字助理(PDA，personal digital assistant)，便攜式計算機，智能遠程控制，或其他類型的處理設備。所謂的精簡型設備表現為它們通常有有限的計算能力和內存。
設備30的元件可以是這種設備的傳統元件。例如，處理器32可以是微處理器，中央處理器(CPU，central processing unit)，數字信號處理器(DSP，digital signal processor)，或特定用途集成電路(ASIC，application-specific integrated circuit)，和它們以及其他處理設備的部分或組合。內存34是典型的電子內存，但是可以包含或包括其他類型的存儲設備，例如光盤或磁盤存儲器。
在這里描述的本發明的微XForms引擎可以全部或部分的分別使用設備30中的內存34和處理器32元件存儲和執行的軟件來實現。例如，微XForms引擎可以至少部分的使用一個或多個由內存34存儲和由處理器32執行的軟件程序來實現。軟件程序在諸如內存34和處理器32的設備元件上被儲存和執行的詳細的行為在技術上很容易理解，因此不在這里詳細描述。
應該注意的是，設備30可以包括其他未圖示的元件，或者其它能夠提供這里描述的可伸縮的XForms處理功能的元件類型和排列。
圖4顯示了基于因特網通信系統40的例子，其中，本發明的微XForms引擎可以被實現。系統40包括通過因特網42與一些家庭44中的設備通信的網絡服務器46。網絡服務器46可以與電子貿易商(eMerchant)相關聯。代表性地，電子貿易商網絡服務器46負責商務邏輯和/或協調事務，通過在因特網42上向家庭44中的設備發送基于XML的文檔49a-49e，來向其它處理設備(例如精簡型設備)提供服務，它使用眾所周知的技術，例如因特網協議(IP，Internet protocol)。
在這個實施例中家庭44的設備被裝備上本發明的微XForms引擎45或現有技術的基于完整XForms1.0的完整XForms引擎47。依照本發明的首要目的，微XForms引擎45被配置為使用在具有有限處理和/或內存性能的精簡型設備上。更典型的，家庭44包括下列精簡型設備電視機46-1，視頻游戲控制機46-2，PDA設備46-3和置頂盒46-4，其中都分別裝備微XForms軟件引擎(XML SW)45-1到45-4。家庭44也可以包含包括音樂自動唱片電唱機46-5，音頻系統46-6，和PC 46-7在內的非精簡型設備來接入到家庭網絡46-8。每個非精簡型設備被分別裝備了完整XForms軟件引擎(XML SW)47-5到47-7。此外，一個或多個精簡型設備46-1到46-4可以被按照圖3中顯示的方式來配置。
在因特網42上從網絡服務器46發送到家庭44中的XML文檔49a-e被使用相應的XForms引擎45或47來處理。對于本發明的微XForms引擎45中的一個的情況，XML文檔49被使用完整的推薦XForms1.0的指定子集通過與相應的精簡型設備的計算和存儲能力相適應的方式來處理，進而提供了本發明的可伸縮特色。
應該注意的是，圖4的系統40中所示的具體排列和配置僅僅作為例子。在其它的實施例中，其它類型的網絡服務器，網絡和設備都可以被使用。那些本領域的技術人員將發現本發明的對于特定的精簡型設備可伸縮的微XForms引擎并不要求那些系統元件的任何特殊的安排和配置。
圖5a顯示的傳統XForms棧51包括一些基于XML的標準，包括完整XML1.0標準51a給出的標準，命名空間(Namespaces)標準51b，XPath1.0標準51c，模式1.0標準51d和完整的XForms1.0 51e。眾所周知，棧的配置圖解地傳達了出現在其它棧元素之上的棧元素是部分地從下面的棧元素所派生的思想。
圖5b顯示了簡化的XForms棧53，包括一些基于簡化規則集的XML的對應圖5a中基于XML標準51a-e的標準。除了命名空間標準53b以外，棧53中舉例說明的每個標準代表了從圖5a的傳統XForms棧51中與它相對應的標準派生而來的規則的指定子集。該簡化的或縮減的標準被作為方針用于開發本發明中用在所謂的精簡型設備中的微XForms引擎的可執行代碼。
圖5a的傳統標準和圖5b的簡化標準在下面進行描述。如同在前面指出的那樣，圖5b的簡化標準對由所謂的“精簡型”設備的具體處理和/或存儲能力的約束決定的不同實施例而各不相同。同樣的，微XForms引擎依照設備處理和存儲的約束是可伸縮的。
首先參考圖5a的棧51，顯示了一套完整的基于XML的標準。從最低的棧層開始，顯示了標注為元素51a的完整XML1.0標準。XML1.0標準51a定義了一種標準的方法用以將標記添加到文檔中。完整的XML1.0工作標準51a并不定義語義集(semantics)也不定義標簽集(tag set)，而是定義了一種元語言(meta-language)(用于創建其它標記語言的語言)。完整的XML1.0標準51a提供了一種工具來定義標簽和它們之間的結構關系。因為沒有預定義的標簽集，也就沒有任何預先理解的語義。所有XML文檔的語義也將或者被處理它們的應用程序定義，或者被樣式表(stylesheet)定義。其它關于完整XML1.0標準51a的細節，可以在發布于http//www.w3.org/TR/REC-xml的“可擴展的標記語言(XML，Extensible Markup Language)1.0(第二版)”(W3C recommendation6Oct.2000)中找到，將其完全引入作為參考。
現在參考圖5b，顯示了與圖5a的完整XML1.0標準51a的相應的部分，標注為簡化XML1.0標準53a。依照一個實施例，該簡化的XML1.0標準53a合并了從完整XML1.0標準51a中定義的39條規則中的11條規則。依照一個實施例，這些規則包括[1]document ∷＝element*[2]element ∷＝STag content ETag[3]Stag ∷＝′<′QName(Attribute)+′>′[4]ETag ∷＝′</′QName′>′[5]content ∷＝element*|Char*[6]Attribute ∷＝Name′＝′′″′Char*′″′[7]Name ∷＝NameChar*[8]NameChar ∷＝Letter|Digit|′.′|′-′|′_′|′′[9]Letter∷＝[A-Z]|[a-z][10]Digit∷＝′0′|′1′|′2′|′3′|′4′|′5′|′6′|′7′|′8′|′9′[11]Char ∷＝Letter|Digit|′！′|′#′|′$′|′％′|′(′|′)′|′*′|′+′|′，′|′-′|′.′|′/′|′′|′；′|′＝′|′？′|′@′|′[′|′\′|′]′|′^′|′_′|′`′|′{′|′}′|′～′[12]Qname::＝(Name′′)？Name。
使用圖5b的簡化的XML1.0標準53a提供了超出使用完整XML1.0標準51a的優點，包括避免不必要的解析，提供更小的內存足印(footprint)，運行時需要更少的內存和避免使用實體或實體引用。
再次參考圖5a，顯示了完整的XML命名空間標準51b。該命名規則51b被創建以解決XML中當不同的標記語言中有的元素和屬性取了相同名字時的問題。一個潛在的命名沖突的例子可以發生在當一個文檔中使用“part”元素來描述”part books”，而同時另一個XML文檔使用“part”元素來描述”part cars”的時候。XML命名空間標準51b試圖通過擴展數據模型以便允許元素類型名和屬性名適合于URI(uniform resourceidentifier，統一資源標識)來改進這種情形，從而去除不確定性(ambiguity)。URI賦予本地名字全局標識來去除在像網絡這種分布環境中的混淆。其它命名空間的細節可以在發布于http//www.w3.org/TR/REC-xml-names的“XML中的命名空間(Namespacein XML)”(W3C 14 Jan.99)中找到，在此引入作為參考。由于完整的命名空間標準51b的極小的內存足印，本發明完全合并了未加修改的命名空間標準51b(參看完整命名空間標準53b)。
再次參考圖5a，顯示了完整的XPath1.0標準51c。該完整的XPath1.0標準51c定義了一種XML用于定位XML文檔中的各部分的XML路徑語言(XML path language)，設計為供允許并給予了將XML中標記出的信息從一個字符集轉換到另一個的能力的XSLT和XPointer使用，。其它關于可擴展XPath1.0標準51c的細節可以從發布于http//www.w3.org/TR/xpath的“XML路徑語言(XPath)版本1.0”(W3CRecommendation 16 Nov.1999)找到，在此引入作為參考。
現在參考圖5b，顯示了與完整XPath1.0標準51c相對應的部分，引用為簡化的XPath1.0標準53c。雖然完整的XPath1.0標準包含大約39條規則，而依照一個實施例，簡化的XPath1.0標準53c合并了從完整的XPath1.0標準51c定義的完整規則集中派生的下列子集Selector ∷＝Path(′|′Path)*[2]Path ∷＝′/′(Step(′/′|′//′))*(Step(Number)？|′@′NameTest)[3]Step ∷＝′.′|(NameTest |′child∷′NameTest)(′[′Digits′]′)？[4]NameTeat ∷＝QName|′*′|NCName′′′*′[5]QName ∷＝(NCName′′)？NCName[6]NCName∷＝(Letter|′_′)Char[7]Digits∷＝
+[8]Letter∷＝[A-Z]|[a-z][9]Char ∷＝Letter|Digit |′！′|′#′|′$′|′％′|′(′|′)′|′*′|′+′|′，′|′-′|′.′′/′|′′|′；′|′＝′ |′？′|′@′|′[′|′\′|′]′|′^′|′_′|′`′ |′{′|′}′|′～′。
上面定義的規則子集的目標僅僅是定位一系列節點。為了定位節點，強加了下列限制(1)唯一可用的軸(axis)是子(child)軸，(2)謂詞(predicate)的數量是1或者0，(3)如果謂詞存在，那么謂詞表達式(也就是PredicateExpr)必須是指向必須能在節點集中找到的節點的位置的整數，并且(4)沒有XPath函數(也就是不能使用數學或字符串操作)。
引入上述的簡化規則集提供了超過使用完整規則集的優點。僅使用孩子(child)，后裔和屬性軸代替完整的XPath1.0標準51c中的13個坐標，并且僅使用數字作為謂詞，代替了表達式或函數，導致了XPath軟件內存足印的較大減少，而且保留了XPath需要的大部分能力。
再次參考圖5a，顯示了完整的XML模式1.051d。完整的XML模式1.0包括兩部分XML模式第一部分的規范和XML模式第二部分的規范。XML模式第二部分的規范被稱為XML模式數據類型，并且它定義了定義在XML模式中和其他XML規范中使用的數據類型的工具。
一般而言，模式允許其準確性XML文檔被機器驗證。換句話說，模式一旦被構造，就允許XML應用程序處理文檔并確定它是否符合模式中設置的約束集。因此，模式的另一個名字是數據模型。XML模式由例如類型定義和元素聲明的組件組成，。這些可以被用來評定結構良好的元素和屬性信息項的合法性，并且此外還可以指定到這些項和它們的后裔的擴充。其它關于完整的模式1.0標準51d的細節可以在發布于http//www.w3.org/TR/xmlschema-2/的“XML模式第二部分數據類型”(W3C Recommendation 02 May.2001)找到，在此引入作為參考。
現在參考圖5b，顯示了與圖5a的完整的XML模式1.0標準51d相對應的部分，標注為簡化的模式1.0標準53d。依照一個實施例，簡化的模式1.0標準53d僅包括與數據類型相關的XML模式第二部分規范的子集。因而，在實施例中，簡化的模式1.0標準53d僅合并了“Integer”和“String”數據類型來實施XML文檔的驗證。使用簡化模式1.0標準53d的首要優點是它提供了小得多的內存足印。在實施例中，沒有包括在簡化模式標準53d中的數據類型的例子有double，float，duration，date，dateTime，time，gYearMonth，gYear，gMonthDay，gDay，gMonth，Boolean，base65binary，hexBinary，QName，NOTATION和anyURI。需要注意的是因為沒有包括全部范圍的數據類型，一些功能被犧牲了。例如，沒有合并‘date’數據類型失去了在該字段上執行加法和/或減法操作的能力。然而像指出的那樣，明智的減小內存足印允許精簡型設備支持XForms并保留足夠的功能。再次參考圖5a，在棧的頂部顯示了完整的XForms1.0 51e。如圖所示，由于在棧的頂端，完整的XForms1.0 51e被部分地從每個棧51中在下面的標準派生。完整的XForms1.0 51e提供了分別描述把表單做什么和把表單怎么呈現給用戶的能力。這允許了靈活的表達選擇，使用于經典的XHTML表單控件，和諸如WML的其它表單控件集的方法成為可能。XForms允許建立新的平臺無關的標記語言用于在XForms處理器和遠程實體之間在線交互。關于完整的XForms1.0 51e的細節可以在上面引用的2002年1月18日XForms1.0 Working Draft，http//www.w3.org/TR/xforms/上找到。現在參考圖5b，顯示了與完整的XForms1.0 51e相對應的部分，引用為簡化的XForms1.0 53e。依照棧的繼承組織結構，簡化的XForms1.0 53e部分地被從每個示出的下面標準派生。因此，簡化的XForms1.0 53e合并棧53中下面的簡化標準的限制，例如，如為上面實施例描述的那樣。除了從下面標準中合并的限制以外，簡化的XForms1.0 53e作為一種簡化的規則集從完整的XForms1.053e中派生。該簡化的規則集包括有限數量的約束，包括靜態約束(staticconstraint)，模式約束(schema constraint)，表單控件約束(formcontrol constraint)和動作約束(action constraint)。每個約束類型將在下面更詳細的描述。
靜態約束被用于定義Xforms模型的規則(regulation)并且定義施加在結果XForms實例文檔上的限制。一些包含在簡化XForms1.0 53e中的靜態約束的例子包括type，required，minOccurs，maxOccurs，isValid，calculate和enumeration。模式約束被合并入簡化的標準來定義XForms模型65(圖6)中每個元素的細節。合并的模式約束的例子是名字字符串的字符數必須大于一的要求。合并入簡化的XForms1.0 53e的約束的第三種類型與表單控件相關。在一個實施例中，只有“input”和“output”表單控件被合并入簡化的XForms1.0 53e之中。在簡化的標準中，“輸入”表單控件被包括在內以便許可像名(first name)這樣的一行字段的條目并且“輸出”表單控件被包括在內以便呈現已經填在表單的字段中的信息，例如，在地址表單中缺省的國家字段。最后被合并入簡化XForms1.0 53e的約束類型與動作相關。在一個實施例中，“submitInstance”被用于提交XForms的數據實例(也就是Xfroms模型的填寫好樣式)。
使用簡化的XForms1.0 53e提供了具有用比完整的XForms1.0 51e小的實現來覆蓋較廣范圍的表單的能力的優點。
處理電子表單圖6顯示了本發明在因特網網絡環境的實現。在這個例子中，本發明的微XForms引擎61被存儲在精簡型設備68的內存中，該精簡型設備68可以是，例如PDA或手機。該微XForms引擎61被顯示為由三個組成軟件組件構成，簡化的XPath軟件組件61a，輕量級模式軟件組件61b和XML解析軟件組件61c。需要注意的是，每個組成微XForms引擎61的軟件組件61a-61c代表遵守由一個或多個在圖5b的棧53中顯示出的簡化的標準定義的有限的規則集的可執行代碼。
本發明的微XForms引擎61被配置以使用在像因特網這樣的網絡上用精簡型設備處理電子表單。下列描述被做為包括在在因特網中在精簡型設備上使用本發明的微XForms引擎61處理電子表單的步驟的示例說明而提供的。
繼續參考圖6，與電子貿易商關聯的網絡服務器62，在因特網63上把基于XML的電子表單DOC1 64傳送到包含微XForms引擎61的精簡型設備68。該精簡型設備68在四個階段里處理接收到的電子表單DOC1 64。處理電子表單的階段包括向用戶顯示表單，由用戶填寫該被顯示的表單，驗證填寫好的表單，和把表單提交回發信方(也就是網絡服務器62)。每個階段在隨后描述顯示電子表單依據在精簡型設備68上從網絡服務器62接收的XML文檔DOC1 64，微XForms引擎61被分配在顯示階段的第一部分創建XForms模型65和在這個階段的第二個部分顯示該XForms用戶接口66的任務。微XForms引擎61提供一種普通的接口來動態的把任何用戶接口(UI，userinterface)66與XForms模型65相綁定。因為微XForms引擎61是基于XML技術，它把表單(也就是DOC1 64)的數據和邏輯從它的表示中分離出去。顯示被用戶接口66控制并且數據和邏輯被XForms模型65控制。使用這個方法，表單可以獨立于最終用戶如何與表單交互而被定義。需要注意的是，用戶接口66不是在精簡型設備68上的輕量的或被剝離的版本。而是，它代表一些用于精簡型設備的用戶接口中的一個，其在技術上眾所周知，例如包括，WML接口，語音激活接口，手寫接口，手寫識別接口，或者HTML接口。因為XForms將表示從下面的表單數據和邏輯分離出去，無論設備UI是怎樣，表示都是可以理解的。同樣的，由用戶接口66控制的顯示對本發明不重要因此不再進一步地討論。
XForms模型65包括兩個組件，數據結構組件65a和XForms擴展組件65b。數據結構組件65a本質上是從包含在傳送的文檔DOC1 64中的部分數據所派生得到的數據模型。Xforms擴展組件65b是派生自傳輸文檔DOC1 64中的部分其它數據，文檔DOC1 64包含一個或多個約束和/或用于聯系派生數據模型的數據依賴。XForms模型65由微XForms引擎61從在精簡型的設備(也就是客戶端)上提供的數據構造出來的，如下所述。然后，構造好的數據結構組件65a被依照模式進行驗證，該模式是使該類型的文檔能被在電子貿易商和精簡型的設備間傳送的一套約束或規則。在當前描述的實施例中，模式是簡化的模式1.0標準53d，它只包括XML模式第二部分規范的子集，如上所述。該XML模式第二部分的子集提供了多種數據類型，用戶提供的數據可以據其進行驗證。例如，在包括年齡字段的表單中，模式可以指明年齡是三位非負整數。一旦構造好的數據結構組件65a根據模式被驗證，它被微XForms引擎61聯合XForms擴展組件65b使用，該擴展組件65b包括一些必須被許多數據字段遵守的約束，用以從用戶提供的輸入數據建立實例文檔67。一個可以由XForms擴展65b施加的靜態約束的例子是，“zip code”必須是5位數。可以施加的動態約束的例子是，如果病人指定了他的性別為男性，那么就不能指明他已懷孕。實例文檔67然后在將它提交回源服務器(也就是電子貿易商)之先被驗證，將在下面描述。
圖7是一般的流程圖用以舉例說明與通過微XForms引擎61的組件創建XForms模型65和創建XForms實例文檔67相關聯的步驟。顯示電子表單的處理開始于接收到的XML文檔DOC164由輕量的SAX解析器61d解析，該SAX解析器61d是XML解析器61c的軟件組件之一，而XML解析器61c依次是微XForms引擎61的軟件組件。SAX，代表“簡單應用程序編程接口(simple application programming interface)”或“簡單API”，是為通過基于事件的架構解析XML文檔而設計的標準編程接口。也就是說，SAX是一種類型的事件回調(call back)接口，藉此應用程序開發人員實現一套“回調”方法或例行程序，每個對應一種在解析XML文檔實例的過程中可能發生的事件。本質上，SAX解析器提供了對在XML文檔中所有標準內容上觸發的事件的支持。一個SAX解析器的功能是在XML文檔中讀并根據XML文檔中所面臨的事件觸發事件而不是對文檔內容進行操作。SAX事件響應下列XML文檔內容而被觸發打開或關閉元素標簽，PCDATA和CDATA段，處理指示、注釋和實體的聲明。
仍然參考圖7，輕量級SAX解析器61d從解析接收到的文檔DOC1 64(也就是電子表單)中觸發SAX事件72。如上所述，輕量級SAX解析器61d是一種用于基于事件的解析XML文檔(例如，DOC1 64)的接口。輕量級SAX解析器61d是依照命名空間標準53b的完整規則集和簡化XML1.0標準53a的簡化規則集構造的軟件模塊，如前面圖5b中所述。關于SAX的更多細節可以在http//www.megginson.com/SAX/index.html和那里嵌入的鏈接上找到，在此引入作為參考。
合并在XML解析器61c中的事件路由器73(但沒有在圖6中單獨畫出)最初捕獲由輕量級SAX解析器61d觸發的SAX事件72。把SAX事件72傳遞到輕量級模式組件61b或到輕量級DOM(Document Object Module，文檔對象模塊)處理程序61e或基于具體SAX事件內容到用戶接口66，是事件路由器73的功能。需要注意的是，輕量級模式組件61b是依照簡化模式1.0標準53d的簡化規則集構造的軟件模塊，如上面所述。需要進一步注意的是，輕量級DOM處理程序61e負責XForms實例文檔67的構造。輕量級DOM處理程序61e使用完整的命名空間標準53b，但是，因為實例文檔67是基于簡化的XML1.0標準53a和簡化的XForms 1.053e，輕量級DOM 61e最小化了為實例文檔67中的每個元素儲存的信息量。
在事件路由器73確定了負責處理給定的SAX事件的實體之后，該事件被傳遞到適當的實體。XForms模型65被基于傳遞到輕量級模式組件61b的事件而建造。XForms實例文檔67被基于傳遞到輕量級DOM解析器61e的事件而建造。這樣，如果合法的XForms文檔DOC164被做為輸入提供，在顯示步驟的結束，XForms模型65將已經被構造。否則，異常被觸發。
事件路由器73也發送為表示而接收到的SAX事件到UI66。需要注意，因為基于XML的表單的表示數據是從表單的數據和邏輯分離出去的，完整的表示被發送到精簡型設備UI66以便以適合該設備的方式來處理和顯示。
填寫電子表單在下一階段，用戶填寫表單的程序被執行。當用戶填寫顯示的XML文檔DOC1 64的UI輸入字段時，XForms實例文檔67中對應元素的值也被改變。這因為每個UI輸入字段通過XPath綁定被鏈接到XPath表達式而發生的。XPath指出XML文檔(例如，DOC1 64)內部的節點如何被訪問。一般來說，“綁定”通過使用做為定位器(locator)的綁定表達式把實例數據節點連接到表單控件或到模型項約束。
圖8是XPath綁定如何被識別以將UI輸入字段綁定到XPath表達式的說明性例子。在該圖例說明中，包含表達式“Octav”的文本框81與XForms數據實例85中的元素“名(firstname)”83通過使用XPath表達式“/name/firstname”相關聯。XPath是UI組件81和XForms數據實例85之間的綁定語言。
如上所述，關于本發明圖5b中微XForms引擎61的簡化XPath組件61a執行XPath綁定操作來把XML文檔中相應的數據實例節點與表單控件相連接。
驗證電子表單在填寫表單過程中的任何一點上，驗證程序都可以被啟動。驗證程序包括根據由微XForms引擎61構造的XForms模型65檢查從XForms實例文檔中發現的信息。
如上所述，由于內存約束的支持是僅僅為XML模式第二部分規范的子集而在輕量級模式組件61b中被提供的，它在以前被用來驗證XForms模型數據結構組件65a。這樣，微XForms引擎61僅檢查Xform實例文檔67的特定元素的值是否對指定的數據類型是合法的。為了根據預先構造的XForms模型65檢查XForms實例文檔67是否合法，下列步驟隨后進行當后序遍歷DOM樹時如果元素包含文本信息那么該信息被規格化，并且如果1)對于該元素，沒有指定數據類型，那么數據實例非法；2)對于該元素，指定了一種數據類型，那么XForms實例文檔根據定義在XForms模型中的類型約束被檢查。如果約束被滿足則繼續。否則，XForms實例文檔非法。
如果元素沒有孩子(樹上的葉子節點)那么它必須被指定類型。
如果沒有指定類型，那么XForms實例文檔非法。
如果所有節點被遍歷并且沒有發生錯誤，那么XForms實例文檔合法。
通過僅提供完整XML模式第二部分規范的子集來創建XForms模型65，根據它來檢查XForms實例文檔，存在創建非法的文檔的可能。然而，這一不期望情況發生的可能性是與通過只保存XML模式規范的有限子集來順應精簡型設備的處理和內存約束的能力來達到平衡的。
提交如上所述，XForms數據實例67在提交程序中被發送回網絡服務器62。任何眾所周知的數據傳輸協議都可被用來提交數據實例67。例如，HTTP和SOAP傳輸協議被一起使用。提交步驟不包括任何微XForms引擎61部分的動作，并且不再進一步詳細討論。
從而顯示出本發明的微XForms引擎61使用在具有處理和內存的需要被約束的特性的精簡型設備上的可伸縮性。同樣的，微XForms引擎61適合使用在較廣范圍的平臺上，例如包括個人數字助理(PDAs，personaldigital assistants)，手機，置頂盒或者其它因特網可用的“精簡型”處理設備。
盡管本發明圖例示出的實施例在這里參考附圖被描述，應該認為本發明并不局限于那些明確的實施例，需要確切指明的是本發明的范圍被權利要求的范圍所定義。
權利要求
1.一種用于在具有有限的處理和存儲能力的設備上處理信息的方法，該方法包括的步驟有使用基于完整XForms規范的指定子集的XForms引擎處理可擴展標記語言(XML)；和利用處理步驟的結果創建合法XForms實例文檔。
2.權利要求1中的方法，其中，處理步驟包括的步驟有顯示，填充，驗證和提交該XForms實例文檔。
3.權利要求2中的方法，其中，顯示步驟包括顯示對應設備的用戶接口(UI)組件，上述被顯示的組件被從包含在上述實例文檔中的下面數據解耦合。
4.權利要求3中的方法，其中，用戶接口組件是WML用戶接口，HTML接口，支持語音識別的用戶接口和支持手寫識別的用戶接口之一。
5.權利要求1中的方法，其中，XForms引擎是實施完整XForms規范的多個不同的子集的作為設備的內存和處理能力的可伸縮引擎。
6.權利要求1中的方法，其中，設備是從包括無線電話，個人數字助理，遠程控制設備，置頂盒和游戲控制臺的組中選出地。
7.權利要求1中的方法，其中，XForms引擎是從推薦的XPath標準中定義的第一規則子集，推薦的模式標準定義的第二規則子集和推薦的XML標準定義的第三規則子集的組中至少選擇一個構造而成。
8.權利要求7的方法，其中，第三規則子集包括一個或多個下列元素[1]document ∷＝element*[2]element ∷＝STag content ETag[3]Stag ∷＝′＜′QName(Attribute)+′＞′[4]ETag ∷＝′＜/′QName′＞′[5]content ∷＝element*|Char*[6]Attribute∷＝Name′＝′′″′Char*′″′[7]Name ∷＝NameChar*[8]NameChar∷＝Letter|Digit|′.′|′-′ |′_′|′′[9]Letter ∷＝[A-Z]|[a-z][10]Digit ∷＝′0′|′1′|′2′|′3′|′4′|′5′|′6′|′7′|′8′|′9′[11]Char ∷＝Letter|Digit|′！′|′#′|′$′|′％′|′(′|′)′|′*′|′+′|′，′|′-′|′.′|′/′|′′|′；′|′＝′|′？′|′@′|′[′|′\′|′]′|′^′|′_′|′`′|′{′|′}′|′～′[12]Qname ∷＝(Name′′)？Name
9.權利要求7中的方法，其中，第一規則包括一個或多個下列元素[1]Selector∷＝Path(′|′Path)*[2]Path∷＝′/′(Step(′/′|′//′))*(Step|′@′NameTest)[3]Step∷＝′.′|(NameTest|′child∷′NameTest)(′[′Digits′]′)？[4]NameTest ∷＝QName|′*′|NCName′′′*′[5]QName ∷＝(NCName′′)？NCName[6]NCName ∷＝(Letter|′_′)Char[7]Digits ∷＝
+[8]Letter ∷＝[A-Z]|[a-z][9]Char∷＝Letter|Digit|′|′|′#′|′$′|′％′|′(′|′)′|′*′|′+′|′，′|′-′|′.′′/′|′′|′；′|′＝′|′？′|′@′|′[′|′\′|′]′|′^′|′_′|′`′|′{′|′}′|′～′。
10.一種用于處理可擴展標記語言的文檔的裝置，該裝置包括可操作用以處理基于完整的XForms規范的子集的指定子集的文檔的XForms引擎，其中，XForms引擎的處理結果被用來輸出合法的XForms實例文檔。
11.權利要求11中的裝置，其中，XForms引擎包括簡化的XPath組件，輕量級模式組件和XML解析器組件。
12.一種制造的商品包括包含了一個或多個用于處理可擴展標記語言(XML)信息的軟件程序的機器可讀的存儲介質，上述制造的商品適合使用在配置成支持完整XML標準集的指定子集的精簡型處理設備上，其中，該一個或多個軟件程序當下列這些時候執行使用基于完整XForms規范的指定子集的XForms引擎處理可擴展標記語言(XML)文檔；和利用處理結果創建合法的XForms實例文檔。
13.一種用于在具有有限處理和存儲能力的設備上處理信息的系統，該系統包括a)至少一個向上述設備提供基于可擴展標記語言(XML)的文檔的源設備；和b)配置成處理上述接收到的基于XML文檔的處理設備，上述處理設備包括基于完整XForms規范的指定子集的XForms引擎。
14.權利要求13中的系統，其中，上述XForms引擎包括XPath軟件組件，輕量級模式軟件組件和簡化的XML解析器組件。權利要求13中的系統，其中，上述XForms引擎進一步包括用戶接口軟件組件。
15.權利要求13中的系統，其中，上述XForms引擎進一步包括用戶接口軟件組件。
全文摘要
無線電話，個人數字助理(PDA)，智能遙控，或其他網絡處理設備包括可伸縮的電子表單處理引擎，該引擎支持W3C推薦的XForms標準的指定子集。可以根據設備的計算和存儲能力為該設備選擇該指定的子集。有利的是，本發明允許“精簡型”設備處理電子表單而無須完整的W3C推薦XForms標準的執行。
文檔編號G06F12/00GK1777886SQ03814423
公開日2006年5月24日 申請日期2003年6月16日 優先權日2002年6月20日
發明者Y·阿薩發蒂, O·奇帕拉, A·亞斯森, K·朱 申請人:皇家飛利浦電子股份有限公司