?????????XML以其開放、自描述、向前兼容的特性逐漸成為數據交換的事實標準，并將觸角伸展到金融行業的不同領域，盡管道路不是很平坦，頗有些泥濘，但XML在金融業的應用依然向前。

漸行漸近的行業標準
????????目前，針對不同的金融應用領域已經出現了幾種不同的XML 格式。如Interactive Financial Exchange (IFX)和 Open Financial Exchange (OFX)標準，它們處理的對象是消費者和其他形式的小額銀行業務。
????????Financial Information eXchange (FIX)是作為產權交易數據的標準通信協議出現的。SWIFT在加入 ISO 15022 XML 工作組后，已經采用XML 作為主要的表示格式，并把它的歷史悠久的數據模型轉化成了 XML 形式。Financial Products Markup Language（金融產品標記語言，FpML）用于金融衍生市場事務，通常用于錯綜復雜的協商。eXtensible Business Reporting Language（可擴展商業報告語言，XBRL），主要用于商業報告和數據的準備與交換。
????????上述這些標準都不能涵蓋所有的銀行業務。會計和審計制度的不同使這些標準很難應用在國內的金融行業。國內也缺乏專門的機構和人才對金融數據交換制定適合國情的，并具有一定權威性的標準，但是這些標準具有重要的參考意義不容忽視。


邁過五道坎
????????XML的誘惑已經使很多銀行和金融公司開始制定內部的XML標準用于數據交換和存儲。關于標記的制定、屬性值的枚舉、交易要素的多少、元素的細分等環節的隨意編寫也嚴重損害了XML的標準意義。不同銀行在相同領域使用不同的XML報文規范，以及同一個銀行內部不同系統之間使用不同的XML報文規范在很大程度上削弱了XML語言的開放性。
????????同時，在XML實際用于金融數據交換時要處理好以下五個問題，邁過這五道坎之后，XML將發揮出真正的實力。
????????1. DTD和Schema
????????為了說明XML詞匯表的語法規則，可以采用文檔類型定義描述（DTD）。DTD使用正式的語法定義XML文檔的結構和允許值。通過創建DTD，能夠正式而精確地定義詞匯表，從而使解析器可以利用DTD驗證文檔實例的有效性和完整性。遺憾的是DTD的數據類型對XML文件的約束顯得并不詳盡。例如，賬號和申請人的名字均被描述成#PCDATA（字符串）。但是賬號是一個整數，還可能是一個32位長的整數。另一個遺憾是，DTD使用非XML文件來描述XML文件。使用XML Schema則可以在一定程度上解決上述問題。XML Schema是一個良好格式的XML文件，提供了多種數據類型定義并允許對這些定義進行擴展、限制和組合以創建自己的復雜類型。但是需要注意的是XML Schema規范正在發展之中。
????????作為銀行跨系統的應用，使用DTD或XML Schema可以更好的表現和理解用于交換的XML文檔結構，并對XML文檔中的結構和內容錯誤進行指示。但是一般自定義的XML報文均缺少DTD或XML Schema定義，文檔規則隨意且不斷修改。這也許在一個系統內部的交換沒有什么問題，但對于跨系統和跨銀行之間數據交換則會帶來認識的差異和效率的低下。
????????2. 長度與性能
????????自解釋的一個主要后果就是XML文檔長度難以控制。標記和屬性的顯示大大加長了報文長度。報文長度的增加產生了兩個方面的副作用：報文發送的成功率降低以及解析報文的內存和CPU占用增加。不論是使用SOCKET還是消息中間件進行報文傳遞一般都有報文長度的限制。隨著報文長度的增加，通信的成功率明顯降低，尤其是廣域網通信。另外無論是使用DOM還是SAX解析XML文檔，存在相當的內存和CPU資源占用。
????????金融交易一般交易元素眾多，特別是加入客戶關系管理和綜合賬戶信息后，發送和返回的信息明顯增多。常用的一種方法是對報文壓縮和進行傳遞，實際應用中一般壓縮比可以達到30～50%。另外就是使用縮寫，例如，將Transaction _Account _Number寫成tranAccNum，可以降低報文長度，在一定程度上能夠避免人們將過多的注意力集中于標記而忽視真正的內容，當然也不能過于簡單，否則失去了使用XML語言的意義。將某些信息作為XML屬性進行定義也可以減少文檔的長度。
????????3. 內存管理
????????所有的XML解析器基本上都分成兩類：基于樹結構的接口，如文檔對象模型（DOM）;基于事件的接口，如簡單XML API （SAX）。DOM類型的接口使用樹型結構作到隨機遍歷和修改XML文檔。但是使用這種類型的接口占用內存較多。當使用XML處理大量的數據交換時會對系統產生壓力，甚至出現系統崩潰。
基于事件的接口可能是一個好的選擇。它不支持對XML文檔的隨機訪問，而是采用一種順序訪問的方式。無論XML文檔的大小，所用內存的多少基本上是一定的。同時，由于在運行時不用創建新的對象，處理器時間占用也較少。但是使用SAX類型的接口編程比較復雜，并且沒有對文檔的后向引用。
????????在實際應用中，如果重視易用性，一般使用DOM接口；如更關注性能優勢則選擇SAX類型的接口較好。當然也可以通過減少XML元素嵌套層數減少DOM解析樹的內存占用。
????????4. 標記粒度
????????元素的粒度在制定XML規范時總能讓人產生困惑。某些內容是合在一起成為一個元素還是分開作為多個元素進行標記？例如姓名，是分成姓和名兩個元素進行標記，還是放在一起作為一個元素？個人覺得關于粒度的標記定義指導原則就是一個：盡量細分。只有細分粒度越小，才可能支持各種形式的組合。另外許多信息來源于遺留系統，如果采用囫圇吞棗的方式延用其信息格式，表面上看節省了數據細分的難度，但是這對數據的共享和數據的整合會產生重大的障礙。
????????5. 結構化定義
????????很多時候為了提高XML文檔解析的效率或縮短文檔長度，有意識地避免采用多層結構化的XML文檔定義。當然不是說XML文檔沒有根節點，但是會將節點的層次控制在2 ～3層。這顯然違背了XML設計的初衷。沒有了結構的XML文檔同一般的交換報文還有什么差異呢？實際上大量交換的數據和信息存在層次。
????????在金融領域，可以在業務種類和業務要素兩個領域對節點層次進行劃分。首先是業務種類領域。一般交易數據包含報文頭、客戶基本信息、賬戶信息、交易相關信息等幾個大部分組成，其下則包含業務要素領域元素，如賬戶信息領域下就包括賬號、賬戶類型、存期、幣種、冊號、筆號、開戶日期等多個相關業務要素元素。通過這兩個層次的劃分，基本可以說明用于交換的XML報文的層次結構。而業務要素領域元素則可以進一步劃分層次說明相關屬性。