专利名称：使用资源有限的设备处理电子表单的方法和设备的制作方法
技术领域：
本发明一般而言涉及数据处理。具体来说，本发明涉及在诸如因特网的计算机网络上处理电子表单的基于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·朱 申请人:皇家飞利浦电子股份有限公司