XML – 報表資料的新大陸

   隨著B/S系統的普及和XML技術的深入應用，越來越多的資料包裹著XML的外衣被儲存和扔來扔去。這些資料很多源自資料庫，但經過一定的處理，資料更精簡，更貼近應用。如果報表工具能利用這些XML資料，則可以減少資料庫查詢和報表資料運算操作，因為這些XML資料的始作俑者已經完成了這些操作。因此說XML是報表資料的新大陸。

  傳統的報表工具都是只能處理關係型資料庫，基本上不能處理其他資料。隨著時代的發展，一些報表工具加上了處理XML文檔的能力，但需要編程，編寫並配置外掛程式，如此報表程式結構複雜，介面眾多，使用者還需要根據各種規範動手編寫程式，若XML文檔格式有很多種，就需要編寫很多種的外掛程式，報表開發量不小。

   如果實現了一種能處理XML文檔，從中獲得報表資料的通用方法。則在定製報表範本的時候就教育報表引擎如何從XML文檔獲得資料，則對於所有的或大部分的XML文檔無需編程，可減少報表開發量。

  那麼如何通用的處理具有複雜樹狀結構的XML文檔呢？

   大家知道，處理XML文檔有兩種模式，一個是DOM方式，另一個是流模式。DOM方式處理方便，但速度慢耗記憶體，流模式處理速度快，省記憶體但使用不方便。對於.NET平台，使用System.Xml.XmlDocument對象來使用DOM方式處理XML文檔，而使用XmlReader 來使用流模式處理XML文檔。

   W3C國際標準組織設計XML文檔的目標是方便的儲存和交換小型資料包，而不考慮資料的冗餘。因此若實際系統中出現巨大的XML文檔，則大多數情況下可以認為是不恰當的使用XML技術。因此我認為報表工具不應當處理巨大的XML文檔，在此前提下，為了實現方便，採用DOM方式來處理XML文檔。

   在.NET中使用XmlDocument載入一個XML文檔後，會形成一個以XmlDocument為根節點的XML對象樹狀結構，面對這個XML樹結構，擷取其中的資料方法很自然的就是使用XPath技術了。XPath技術就是在XML樹狀結構中，以某個節點作為起始節點，使用特定的描述表示的路徑移動到其他的節點，一般的是向其下層節點移動，比如移動到某個子節點或孫節點，移動到某個屬性等等。

    傳統的報表資料來源模型是兩層的，即使擴充到可以處理XML文檔也只能處理一次，既從根節點出發，使用某個XPath 獲得欄位的值。如此只能處理一次，處理完畢後XML就被扔掉了。但很多時候需要對XML文檔進行進一步處理。此時傳統的兩層報表資料來源模型是不夠的。

    為了能對XML文檔進行精耕細作，需要從傳統的兩層資料來源結構突破到多層的報表資料來源模型。在多層資料來源節點中，每一個節點都映射到XML文檔中的某個節點，而它的子節點則使用XPath路徑映射到XML中的其他節點。如此遞迴迴圈後則多層的資料來源可以映射到XML文檔中的任意節點。多層資料來源模型實際上就是一個資料來源樹，因此處理XML文檔也就是將兩顆樹在某些節點上釘在一起，而XPath就是釘子。因此需要注意各級資料來源節點的XPath配置的連續性，若一個資料來源節點的XPath設定不對，就像它釘錯了XML節點或者乾脆釘在空處。則它本身和所有的子孫節點都都會綁定落空的。

   在實際應用中，由於XML文檔不是專門為報表而產生的，因此報表工具還可能要離開XML文檔來擷取更多的報表資料，此時可能需要從XML文檔跳到其他XML文檔，或者返回資料庫繼續執行SQL查詢。這就非常考驗報表資料來源模型的靈活性了。

    大家都知道RSS文檔是一種XML文檔，在這裡使用部落格園的RSS文檔為例子說明從XML讀取報表資料的過程。首先考察一下RSS文檔的結構，部落格園首頁的RSS文檔URL為 http://www.cnblogs.com/rss.aspx ，根節點為 rss , 然後有個 channel 子節點，下麵包含了RSS文檔的基本資料，然後有若干個item節點，列出了所有文章的基本資料。item節點下面是文章的基本資料，其中 wfw:commentRss 子節點的內容是針對該文章回帖資訊RSS文檔的URL。可以根據這個URL載入的回帖資訊RSS文檔，根據RSS文檔結構可以定義出如下的報表資料來源和RSS文檔的映射關係。

   這裡的RSSXML文檔有三層結構，而且需要動態載入XML文檔進行更深入的處理，因此傳統的兩層結構是肯定不夠的,必須採用多層次的報表資料來源結構。其過程是相當複雜的，步驟為

1. 載入 http://www.cnblogs.com/rss.aspx 處的XML文檔，作為主XML文檔，產生一個System.Xml.XmlDocument 對象，並以該XML文檔對象作為處理的出發點。
2. 使用XPath"rss"遍曆所有符合該路徑的XML節點，很顯然只處理了一個節點，此時當前位置就移動到rss節點。
3. 從當前節點處使用XPath"channel/title"獲得網站標題，使用"channel/link"獲得網站地址，"channel/description"獲得網站說明，"channel/pubDate"獲得文檔發布時間。
4. 從當前節點處使用"channel"遍曆所有符合該路徑的XML節點，很顯然只處理了一個節點，此時當前位置就移動到了"channel"節點。
5. 變數當前節點下的所有的item子節點，並依次設定為當前節點。
6. 從當前節點處使用“title"獲得文章標題，使用"link"獲得文章地址，使用”author"獲得作者，“pubDate"獲得發布時間，"description"獲得文章內容，"slash:comment"獲得回複數，“wfw:commentRss"獲得回複RSSXML文檔的URL。
7. 當處理"wfw:commentRss"節點時，程式根據某個特定的設定載入該節點資料指向的XML文檔，也就是載入針對當前文章的回複RSSXML文檔。並遍曆剛剛載入的XML文檔的所有符合"rss/channel/item"的節點，並依次設定為當前節點。
8. 從當前節點處，使用"author"獲得回複作者，使用”pubDate"獲得回複時間，使用"description"獲得回複內容。
9. 由於RSSXML文檔中的description節點處儲存的時HTML代碼，因此還需要解析HTML代碼並提取其中的純文字內容。

   從上面的步驟可以看出，資料來源結構中的每一個節點都釘到了XML文檔中的某個節點，而且在回複列表這個節點中，程式執行了XML文檔的跳轉，從主XML文檔跳到回複RSSXML文檔，而且是處理樹狀結構的，因此是遞迴操作，很多狀態資訊都由系統呼叫堆疊自動儲存，無需程式自己儲存了。

   如果報表程式能直接連接到部落格園資料庫的話，還可以從文章作者這個節點執行XML文檔到資料庫的跳轉，直接查詢資料庫，獲得文章作者的一些註冊資訊。實事上，這個資料來源樹狀結構中每一個節點都可以發生XML到XML，XML到資料庫，資料庫到XML的三種跳轉，這大大擴充了擷取報表資料的靈活性。

   如果一個資訊系統是純XML應用的話，則報表工具就可以在眾多的XML文檔中跳躍著採集資料而不需要查詢資料庫，就像少林寺的武僧在梅花樁上打架而不用碰地，因此也就不用管下面是JAVA土壤的還是.NET土壤。此時所有的資料庫操作，商務邏輯等等都運行在後台，而報表工具無需關心，只要系統底層安全可靠，則報表模組也就安全可靠，系統底層無論如何修改，只要XML文檔格式不變則報表模組就不需要修改。對於非常複雜的報表資料來源，超出了報表工具的定製能力，則可以編程提供一個XML文檔供報表程式使用。以前系統是直接通過API向報表程式提供複雜報表資料，而現在通過XML文檔以“隔山打牛”的方式向報表程式提供複雜報表資料。此時系統結構更安全，邊界更清楚，體現了XML WebService的指導思想。這種擷取資料的思想可以不局限於報表資料的擷取，還可以應用到其他領域。

   以上討論的應用系統限於B/S系統，但可以設想，C/S系統經過改造，可以通過某種方式向報表工具提供XML資料文檔。

   從上面的討論可以看出，XML確實是報表資料的新大陸，本人寫的報表工具已經初步體現了這種思想。但這種思想可能有點激進，還不成熟不完善，希望大家多多指點。

XDesigner 軟體工作室 2006-8-30