本文考察了一些頂尖的 XML 模式，這些模式爲各種各樣的問題提供瞭解決方案，從基本的 Web 服務到數據描述等等。其中包括涉及到通訊錄和發票的類似數據庫的解決方案。本文選擇模式的標準是根據其實用性和用途，及其在 XML 信息共享和交換方面對 XML 社區的影響。
 |
|
簡單對象訪問協議（Simple Object Access Protocol，SOAP）實際上是一種 Web 服務技術，但 Web 服務中客戶機和服務器之間的數據交換格式是通過靈活的 XML 模式實現的。
Web 服務的主要優點是客戶機和服務器通過網絡進行信息和數據交換的互操作性的層次。SOAP 標準使用 XML 以一種體系結構中立的格式來構造數據，定義數據類型和信息。
對於編程語言來說，只需要提供數據類型和需要在遠程服務器上調用的函數名稱即可。SOAP 庫將用主機語言編寫的信息和格式轉化成 XML 格式的消息，其中包括調用的函數和提供的參數。
通過 W3C 的例子就可以瞭解 SOAP 的結構。調用遠程 SOAP 函數 GetEndorsingBoarder() 的時候，客戶機上的調用程序生成清單 1 所示的 XML 消息。
清單 1. 調用遠程 SOAP 函數
GetEndorsingBoarder()
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetEndorsingBoarder xmlns:m="http://namespaces.snowboard-info.com">
<manufacturer>K2</manufacturer>
<model>Fatbob</model>
</m:GetEndorsingBoarder>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
|
SOAP 客戶機發送的整個消息都放在 SOAP 信封中。信封的內容就是消息的詳細內容。
被調用的函數顯然是 GetEndorsingBoarder，它包括兩個參數：manufacturer 和 model。由此可見，它把本地的可能採用二進制編碼的字符串轉化成了 XML 字符串。由於 XML 是平臺獨立的，主機使用 SOAP 系統不需要複雜的二進制編碼和解碼就可以交換消息。
服務器通過另一個 XML 編碼的 SOAP 信封返回響應，這一次是函數的返回值。SOAP 請求的響應格式與函數相同，只不過在信封內容的後面加上了 Response，如清單 2 所示。
清單 2. SOAP 請求的響應
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetEndorsingBoarderResponse xmlns:m="http://namespaces.snowboard-info.com">
<endorsingBoarder>Chris Englesmann</endorsingBoarder>
</m:GetEndorsingBoarderResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
|
通常不需要自己編寫 SOAP 消息，SOAP 庫會自動生成。不過 SOAP 信封的結構和簡單性表明使用 SOAP 標準共享信息很簡單。
SOAP 大大簡化了交換消息和調用遠程函數的工作。遠程過程調用（Remote Procedure Call，RPC）標準需要複雜的方法來處理二進制數據的序列化，發送結構化更高的信息需要詳細的聲明和雙向的信息轉換。
使用 SOAP，XML 序列化大大降低了這種複雜性，使得跨平臺、跨語言集成和數據交換更加簡單。
 |
|
Web 服務描述語言（Web Services Description Language，WSDL）提供了一種描述 Web 服務（大多使用 SOAP）的簡單方法。WSDL 允許您描述利用 SOAP 標準所提供的服務和接口。
比方說，可以創建描述某臺服務器上提供的服務的 WSDL 文件，然後把該文件分發給需要這些服務的 Web 服務消費者。通過閱讀和解析 WSDL 文件，消費者能夠瞭解到使用這些 Web 服務需要知道的所有信息，包括可以交換的數據類型、參數以及返回的各種錯誤和其他信息。
再次使用來自 W3C 的例子，可以看到不同遠程函數的聲明和交換的數據都是通過結構的 XML 定義處理的，如清單 3 所示。
清單 3. 不同遠程函數和交換數據的 XML 定義
<?xml version="1.0"?>
<!-- root element wsdl:definitions defines set of related services -->
<wsdl:definitions name="EndorsementSearch"
targetNamespace="http://namespaces.snowboard-info.com"
xmlns:es="http://www.snowboard-info.com/EndorsementSearch.wsdl"
xmlns:esxsd="http://schemas.snowboard-info.com/EndorsementSearch.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<!-- wsdl:types encapsulates schema definitions of communication types;
here using xsd -->
<wsdl:types>
<!-- all type declarations are in a chunk of xsd -->
<xsd:schema targetNamespace="http://namespaces.snowboard-info.com"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<!-- xsd definition: GetEndorsingBoarder [manufacturer string,
model string] -->
<xsd:element name="GetEndorsingBoarder">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="manufacturer" type="string"/>
<xsd:element name="model" type="string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- xsd definition: GetEndorsingBoarderResponse
[... endorsingBoarder string ...] -->
<xsd:element name="GetEndorsingBoarderResponse">
<xsd:complexType>
<xsd:all>
<xsd:element name="endorsingBoarder" type="string"/>
</xsd:all>
</xsd:complexType>
</xsd:element>
<!-- xsd definition: GetEndorsingBoarderFault
[... errorMessage string ...] -->
<xsd:element name="GetEndorsingBoarderFault">
<xsd:complexType>
<xsd:all>
<xsd:element name="errorMessage" type="string"/>
</xsd:all>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<!-- wsdl:message elements describe potential transactions -->
<!-- request GetEndorsingBoarderRequest is of type GetEndorsingBoarder -->
<wsdl:message name="GetEndorsingBoarderRequest">
<wsdl:part name="body" element="esxsd:GetEndorsingBoarder"/>
</wsdl:message>
<!-- response GetEndorsingBoarderResponse is of type
GetEndorsingBoarderResponse -->
<wsdl:message name="GetEndorsingBoarderResponse">
<wsdl:part name="body" element="esxsd:GetEndorsingBoarderResponse"/>
</wsdl:message>
<!-- wsdl:portType describes messages in an operation -->
<wsdl:portType name="GetEndorsingBoarderPortType">
<!-- the value of wsdl:operation eludes me -->
<wsdl:operation name="GetEndorsingBoarder">
<wsdl:input message="es:GetEndorsingBoarderRequest"/>
<wsdl:output message="es:GetEndorsingBoarderResponse"/>
<wsdl:fault message="es:GetEndorsingBoarderFault"/>
</wsdl:operation>
</wsdl:portType>
<!-- wsdl:binding states a serialization protocol for this service -->
<wsdl:binding name="EndorsementSearchSoapBinding"
type="es:GetEndorsingBoarderPortType">
<!-- leverage off soap:binding document style ...(no wsdl:foo pointing at
the soap binding) -->
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<!-- semi-opaque container of network transport details classed by
soap:binding above ... -->
<wsdl:operation name="GetEndorsingBoarder">
<!-- again bind to SOAP? ... -->
<soap:operation soapAction="http://www.snowboard-info.com/
EndorsementSearch"/>
<!-- further specify that the messages in the wsdl:operation
"GetEndorsingBoarder" use SOAP? ... -->
<wsdl:input>
<soap:body use="literal"
namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"
namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
</wsdl:output>
<wsdl:fault>
<soap:body use="literal"
namespace="http://schemas.snowboard-info.com/EndorsementSearch.xsd"/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<!-- wsdl:service names a new service "EndorsementSearchService" -->
<wsdl:service name="EndorsementSearchService">
<wsdl:documentation>snowboarding-info.com Endorsement Service</
wsdl:documentation>
<!-- connect it to the binding "EndorsementSearchSoapBinding" above -->
<wsdl:port name="GetEndorsingBoarderPort"
binding="es:EndorsementSearchSoapBinding">
<!-- give the binding an network address -->
<soap:address location="http://www.snowboard-info.com/EndorsementSearch"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
|
WSDL 聲明瞭消息類型、默認數據類型和內容以及交換的數據結構。
訪問服務器上 SOAP 結構需要使用的一切信息都可以在這個 WSDL 中找到。大多數語言和環境都提供一種閱讀和解析 WSDL 的機制，以確定可用的函數和數據交換。
WSDL 不僅定義了用於交換信息的 SOAP 接口，通過適當的 WSDL 生成程序，還可用於創建發送請求、生成並格式化響應所需要的代碼。
WSDL 和 SOAP 組成了一個強大的遠程過程調用系統。
|
|
語義 Web（Semantic Web）和語義網格（Semantic Grid）技術都依賴於資源描述框架（Resource Description Framework，RDF）這種靈活的描述語言。RDF 格式實際上是一個標準家族的成員之一。它用於描述信息和資源，使得系統很容易連接和關聯不同的資源。
RDF 是另一種經過 W3C 批准的標準，它用於定義信息和資源。RDF 不需要 XML，但一種用於描述信息的序列化格式採用了 XML。
定義資源需要指定一個包含主語、謂詞和賓語的表達式。比方說，如果描述一個網站的內容，主語就是該網站，謂詞是 “包含信息”，賓語就是內容的類型。建立該網站和其他資源的聯繫，可使用 Friend of a Friend (FOAF) 標記建立兩個資源之間的鏈接。
RDF 的目的是將關於資源和信息的自然語言的陳述轉化爲機器可解析的格式。比如可將 The MCSLP.com Website is authored by Martin C Brown 這句話改寫爲清單 4 所示的 RDF XML。
清單 4. RDF XML 格式的陳述
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:si="http://www.recshop.fake/siteinfo#">
<rdf:Description rdf:about="http://www.mcslp.com/ ">
<si:author>Martin C Brown</si:author>
</rdf:Description>
</rdf:RDF>
|
採用 RDF 標準的另一個例子是新聞站點和博客早期提供的連鎖系統，它們使用 RDF 規範定義提要內容和不同的新聞。清單 5 提供了一個例子。
清單 5. 利用 RDF 規範定義提要內容和不同的新聞
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://my.netscape.com/rdf/simple/0.9/">
<channel>
<title>MCslp</title>
<link>http://www.mcslp.com</link>
<description>MCslp Projects</description>
</channel>
<item>
<title>Voice enabling XMLtitle>
<link>http://mcslp.com/?p=295link>
</item>
...
</rdf:RDF>
|
RDF 標準最初設計的目的是描述 Web 上的資源、內容和關係。但是 RDF 現在變成了用於描述一般信息、資源和關係的標準。
語義 Web 和網格技術都需要定義資源及其之間的關係，使應用程序能夠使用不同的信息，並且可以把數據捆綁在一起。
|
|
記錄聯繫方式對所有商務應用程序都非常重要，通過有效的 XML 結構來捕獲這些信息可以簡化此類數據的處理。
聯繫信息變化可能很大，因此應該選擇 XML 。比如，有些公司和個人可能有多個地址、電話號碼和電子郵件帳戶。在 XML 結構中很容易聲明多個此類信息片段。
vCard 結構經常在 Internet 上用於表示聯繫信息，它獨立於平臺，很容易生成和導入不同的應用程序。它支持 XML 結構的某些靈活性，但實際上是一種基於文本的簡單格式，使用聲明性字段和擴展來提供信息。不同於 XML，vCard 格式是扁平文本，就是說不能直接向各種元素增加信息。電話號碼是一個很好的例子，它不一定和某個地址關聯，而僅僅作爲記錄中的另一個電話號碼。
W3 聯盟提出一種 vCard 格式的 XML，它採用 RDF XML 標準，以便於格式化和交換聯繫信息。採用 RDF 框架可以在聲明過程中保留一些結構化信息。比如，RDF 標準支持使用包、序列和替代來描述數據。包支持多次聲明一個對象（比如多種角色），並且可以在序列不重要時使用包。序列用於定義對象的次序，比如機構中人員角色的層次結構。替代允許從列表中選擇一項，比如多個電子郵件地址。
清單 6 顯示了虛擬人物 Charles Perston 的 vCard。
清單 6. Charles Perston 的 vCard
BEGIN:VCARD VERSION:3.0 N:Perston;Charles;;; FN:Charles Perston ORG:Perston Technology; EMAIL;type=INTERNET;type=WORK;type=pref:[email protected] TEL;type=WORK;type=pref:01234 567890 item1.ADR;type=WORK;type=pref:;;Perston House;Perston;Perstonshire;P1 0NS;UK item1.X-ABADR:gb X-ABUID:5AE47BB6-4E0F-4558-980C-BD3066FA6154/:ABPerson END:VCARD |
採用 vCard XML 標準，可用清單 7 中的結構表示同樣的信息。
清單 7. 使用 vCard XML 標準表示 Charles Perston
<vCard:vCard xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
xmlns:foaf="http://xmlns.com/foaf/0.1/" vCard:version="3.0"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" vCard:class="PUBLIC"
xmlns:vCard="x-urn:cpan:ascope:xml-generator-vcard#">
<vCard:fn>Charles Perston</vCard:fn>
<vCard:n>
<vCard:family>Perston</vCard:family>
<vCard:given>Charles</vCard:given>
</vCard:n>
<vCard:adr vCard:del.type="pref;work">
<vCard:street>Perston House</vCard:street>
<vCard:locality>Perston</vCard:locality>
<vCard:region>Perstonshire</vCard:region>
<vCard:pcode>P1 0NS</vCard:pcode>
<vCard:country>UK</vCard:country>
</vCard:adr>
<vCard:email vCard:email.type="internet;pref;work">[email protected]
</vCard:email>
<vCard:org>
<vCard:orgnam>Perston Technology</vCard:orgnam>
</vCard:org>
</vCard:vCard>
|
XML 格式更長，但容易理解所看的內容以及各部分之間的關係。這種格式可以瞭解更詳細的信息和細節。比方說，很容易在地址中找到需要的國家，在標準 vCard 輸出中該信息是比較隱含的。
再比如，很容易使用 XPath 或者 SAX 事件提取國家的列表，以便了解位於不同地區的聯繫人的數目。
|
|
能夠編寫文檔，然後以多種不同的輸出格式創建它，這曾是許多開發團隊多年來的夢想。通過 DocBook XML 就可以實現，它不僅保持了語義標記，也保持了對資料格式化與輸出的控制。
控制語義可以指定組成文檔的章節和段落。在段落中可進一步詳細規定包含的項。比方說可以將命令和函數名放在單獨的標籤中，如清單 8 所示。
清單 8. 使用單獨的標籤包裝命令和函數
<para>The <command>compile</command> takes the source code of the material and builds a new class based on the filename. For example, if the filename is <filename>HelloWorld</filename> then the name of the class generated will be <classname>HelloWorld</classname>. |
顯示不同的元素時可以選擇不同的輸出樣式和格式，也可選擇相同的樣式。更重要的是，因爲語義信息回會被返回（比如文檔可能包含對類名的引用），所以可以在編寫索引時用它生成一個列表（該列表包含文檔中詳細描述的所有類名）。
除了語義標記外，文檔的章節和不同部分還可以用特殊的 ID 標記，用這些 ID 建立文檔不同部分的鏈接。有些類型可自動完成（章節、部分以及其他生成目錄的類型），其他則需要明確建立到其他部分的鏈接。
轉化成目標格式的時這些鏈接可以自動轉換成適當的格式。比如，這個鏈接會轉換爲適當的 HTML 頁面或頁面中錨的鏈接。如果要生成 PDF，則可以包含目標章節的頁碼。
這種轉換由 XSLT 樣式表完成。現有的標準 DocBook XSLT 樣式表支持到標準 HTML、XHTML、PDF（通過 FO 標準）、Texinfo、Java™ Help 和 Man 頁面的轉換。使用標準樣式表還可以將數據轉化成各種不同的大小和風格，書籍、A4 頁面和幻燈片。
各種輸出格式和標記的靈活性意味着：當創建文檔時，可以使用相同的文檔源代碼提供打印的手冊、內嵌式的幫助、man 頁面、在線和上下文感知的信息。使用更傳統的模型，可以分別編寫這些元素。
DocBook XML 在技術文章社區得到了廣泛的認可，很多公司所有的文檔全部採用 DocBook XML 標準（或它的一個子集）。
|
|
FIX 是衆多企業間數據交換格式之一，用於在商業活動中交換信息。此類交換信息通常很重要，比如交易支付數據、股票價格和商業信息的交換。
這些需要傳輸的信息有時候是非常小的包，有時候又是大段的數據。此類信息交換的傳統格式是鍵/值對，這種形式的信息交換效率非常低。使用 XML 可以簡化傳遞的數據結構，尤其是複雜的數據。
在基於 XML 的優化版本中，開發人員設法壓縮了數據文件的大小，同時使數據更易於閱讀。股票數據被壓縮到了舊格式的四分之一大小。
除了典型的商業應用外，FIXML 不適合用於其他領域。但如果使用 FIXML 可以提高商業效率，結果是每個人都會受益。
|
|
可縮放向量圖形（SVG）是一種描述繪圖的 XML 標準。使用 SVG 可以描述線條、形狀、位置及其之間的關係。最有吸引力的是這些信息可以輸出爲需要的格式，包括可縮放的圖形和固定的圖片。
SVG 解決了傳統繪圖過程中的一些重要問題。一般是使用專門的繪圖程序完成的。在不同程序之間共享信息和繪圖一般來說非常困難。保存爲 SVG 意味着任何支持 SVG 的應用程序都能讀取和處理這些文件。
繪圖的另一個問題是，將它輸出爲最常用的（尤其是 Web 上）格式時，必須在顯示或者結合到其他文檔前翻譯爲位圖格式（比如 JPEG 或 PNG）。這種傳統的方法存在一些問題。首先，原始繪圖必須明確（通常是手工）導出爲位圖格式。
其次，由於位圖格式以原始繪圖的逐像素表示爲基礎，爲保證圖像的質量必須小心選擇和輸出目標匹配的尺寸和分辨率。比如，屏幕顯示的分辨率需要 72dpi（或 96dpi）以便和多數監視器的標準分辨率匹配。打印輸出則需要 300 到 2400 DPI。因此和原始文件相比生成的圖像文件可能非常大。
雖然在 PostScript 和 Encapsulated PostScript 之前已經存在基於向量的格式，但是對 CPU 的要求非常高，不適合屏幕顯示。
和其他任何向量圖像格式一樣，SVG 也採用各種形狀的列表來描述圖像內容，而不是生成像素表示。比如矩形只需要給出左上角作爲起點，再加上兩條邊的長度就行了。圖像的描述用 XML 表示。標籤包括直線、矩形、多邊形、圓等等，可以控制這些元素的樣式和格式。
清單 9 給出了一個例子。這裏繪製了一個矩形、一個透明的圓和一個三角形。
清單 9. 簡單的圖形
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="100%" height="100%" version="1.1" xmlns="http://www.w3.org/2000/svg"> <polygon points="200,100 300,200 150,250" style="fill:#cccccc; stroke:#000000;stroke-width:1"/> <rect x="20" y="20" width="250" height="250" style="fill:blue;stroke:black;stroke-width:1; fill-opacity:0.1;stroke-opacity:0.9"/> <circle cx="100" cy="50" r="40" stroke="red" fill="red" style="fill-opacity:0.5"/> </svg> |
圖 1 顯示了生成圖像的位圖。
圖 1. 圖像的位圖版本
SVG 格式描述圖像的文件只有 500 多字節，PNG 接近 9 KB。
SVG 使繪圖變得更小、更容易使用以及更容易兼容不同的應用程序。
|
|
Dublin Core 標準是一種信息分類方法，常用於圖書館。Dublin Core 標準有一個 XML Schema 定義瞭如何使用 XML 描述這類信息。Dublin Core 可以有效地對各種信息編目，並且使它們易於修改、查詢和使用。
Dublin Core 目前在信息描述和定義中的應用使語義 Web 得以現實。通過使用一種統一的標準來描述數據，同時，更重要的是使用精心設計並經過實踐檢驗的解決方案，可以詳細描述其他 XML 文檔中的數據，從而可以在不同來源之間有效地交換和比較信息。
Dublin Core 規範有自己的模式，但其目的是嵌入更大的 XML 文檔，使用 XML 名稱空間定義描述文檔中其他數據所需要的 DC 元素。作爲一個例子，閱讀清單 10 看看如何在 RDF XML 模式中使用 DC 分類系統描述 RDF 實體的內容，比如網站。爲此，可以擴展前面的 RDF 模式 示例中的結構。
清單 10. 在 RDF XML 模式中使用 DC 分類系統描述 RDF 實體的內容
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://my.netscape.com/rdf/simple/0.9/"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rss:channel rdf:about="http://www.xml.com/xml/news.rss">
<rss:title>MCSLP</rss:title>
<rss:link>http://mcslp.com/rss </rss:link>
<dc:description>
MCSLP features information, projects and articles from members of the MCSLP team.
</dc:description>
<dc:subject>MCSLP, Grids, XML, Databases, Programming </dc:subject>
<dc:identifier>http://www.mcslp.com</dc:identifier>
<dc:publisher>MCSLP</dc:publisher>
<dc:rights>Copyright 2008, MCSLP</dc:rights>
</rdf:RDF>
|
清單 10 中使用 DC 元素添加描述、主題、發佈者、版權和標識符信息以便對 RSS 提要分類。
完整的 Dublin Core Metadata Elements Set 包括 15 個元數據元素。
- Title
- Creator
- Subject
- Description
- Publisher
- Contributor
- Date
- Type
- Format
- Identifier
- Source
- Language
- Relation
- Coverage
- Rights
這爲描述信息提供了一個廣闊的範圍。
|
|
XForms XML 標準用於定義表單中的不同成分（字段、單選按鈕和列表等輸入控件）以及希望在表單中提供的信息驗證。
XForms XML 標準和 Web 開發人員熟悉的 HTML、XHTML 表單標記非常相似，並將成爲 XHTML 2.0 標準的一部分。
XForms XML 基於簡單的模型、視圖、控制器格式。模型是表單的整體描述，包括字段、輸入約束以及數據提交方式。視圖定義了出現在表單中的控件、分組及其引用的模型字段。表單控件的格式和呈現由 CSS 控制。
XForms 標準通過更詳細地劃分表單信息擴展了傳統的 HTML 表單定義。填充表單的過程中可使用動態元素（目前一般只能通過 JavaScript 或 Ajax 元素實現）。
清單 11 中可以看到一個簡單的文本輸入框和彈出式的選擇框。
清單 11. 簡單的文本輸入框和彈出選擇框
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xforms="http://www.w3.org/2002/xforms">
<head>
<title>XForms Sample</title>
<xforms:model>
<xforms:instance>
<Name xmlns="">
<FName />
<LName />
<Title />
</Name>
</xforms:instance>
</xforms:model>
</head>
<body>
<xforms:select1 ref="Title">
<xforms:label>Title:</xforms:label>
<xforms:item>
<xforms:label>Mr</xforms:label>
<xforms:value>Mr</xforms:value>
</xforms:item>
<xforms:item>
<xforms:label>Mrs</xforms:label>
<xforms:value>Mrs</xforms:value>
</xforms:item>
</xforms:select1>
<xforms:input ref="FName">
<xforms:label>First name: </xforms:label>
</xforms:input>
<xforms:input ref="LName">
<xforms:label>Last name: </xforms:label>
</xforms:input>
<hr />
<xforms:output value="concat('Hello ',Title,' ',FName,' ',LName)">
<xforms:label>Output: </xforms:label>
</xforms:output>
</body>
</html>
|
可以通過 Firefox XForms 擴展來查看該 XForms 表單。結果如圖 2 所示。
圖 2. 使用 Firefox XForms 擴展查看 XForms 表單
|
|
很多商業活動中的一個老問題是從紙質的客戶發票系統遷移到計算機處理。創建發票結構需要認真考慮各種不同的類型和重複元素。
過去，發票這類商業信息的交換必須建立非常龐大的結構和定義，國際發票信息交換標準包括數百個字段。如果沒有交換數據的有效方法，共享發票、訂單和其他數據會非常困難。
由於沒有統一的標準，很多組織開發出了核心發票標準的各種版本。其中，OASIS 組開發的標準可能是最知名的，也是大量公司和組織認可的一種。
這種結構是 OASIS 開發的更龐大的框架 Universal Business Logic（UBL）的一部分，包括多種模式和工作流，從訂單、打印發票到支付。這個系統非常複雜，不可能在本文中討論，不過如果需要一種靈活、互操作的系統，UBL 是不錯的起點。
|
|
本文考察多種不同的 XML 模式，從簡單的描述框架（RDF）到圖形格式（SVG）再到商業工作流的完整結構（UBL）。無論哪一種，XML 結構和內容的靈活性都大大簡化了這些系統的開發。此外，如果需要在不同的平臺和環境之間共享數據，XML 的跨平臺兼容性使得它成爲一種理想的選擇。對 WSDL 和 SOAP 而言，這是最重要的特性之一。
