專利名稱：一種新的空間信息發(fā)布樣式表處理器的轉(zhuǎn)換方法
技術(shù)領(lǐng)域：
本發(fā)明屬于信息技術(shù)中的空間信息獲取與處理技術(shù)領(lǐng)域，特別是涉及一種新的空間信息發(fā)布樣式表處理器的轉(zhuǎn)換方法。
背景技術(shù)：
地理信息標(biāo)記語言GML(Geography Markup Language)文檔作為包含地理信息的可擴展標(biāo)記語言XML(eXtensible Markup Language)文檔，用于對空間和非空間信息進行編碼，可以用來對異構(gòu)空間數(shù)據(jù)進行集成。但GML本身不是為顯示而設(shè)計的，而地理數(shù)據(jù)的顯示又是空間信息發(fā)布中非常重要的部分，因此，GML文檔需要轉(zhuǎn)換為可顯示的格式再進行發(fā)布。我們選擇W3C推薦的SVG(Scalable Vector Graphics)矢量格式標(biāo)準(zhǔn)。SVG本身也是基于XML的，GML文檔轉(zhuǎn)換到SVG格式實質(zhì)上是將一種格式的XML文檔轉(zhuǎn)換成另一種格式的XML文檔，可以通過樣式表XSLT(XML樣式表轉(zhuǎn)換器)實現(xiàn)，通過將編寫好的樣式表(XSLT)和GML源文件傳遞給XSL處理器執(zhí)行而實現(xiàn)的。
我們從一些與XML、XSL、XSLT相關(guān)的專業(yè)技術(shù)網(wǎng)站上(如W3C組織的http//www.w3c.org/Style/XSL/，http//www.w3c.org/DOM/，http//www.w3c.org/XML/，IBM公司的http//www-900.ibm.com/developerWorks/cn/xml/index.shtml等)可以看到，在作XML格式轉(zhuǎn)化時，首先要分別解析兩個輸入文件源文件，樣式表文件。傳統(tǒng)的XSLT處理器處理的方法是將這兩個文件轉(zhuǎn)換為DOM樹存放在內(nèi)存中，內(nèi)存中的DOM樹的大小一般達到原始數(shù)據(jù)大小的10倍或以上，這對小數(shù)據(jù)量XML數(shù)據(jù)影響不大，如樣式表文件一般都不大，不超過幾百K字節(jié)，將它轉(zhuǎn)化為DOM樹并不占用太多的內(nèi)存和時間，故并不是效率的瓶頸；而GML數(shù)據(jù)源文件可能很大，可能幾十兆甚至上百兆，若轉(zhuǎn)為DOM樹，占用的系統(tǒng)資源太多，很容易造成內(nèi)存溢出。若再加上生成DOM樹所占用的CPU資源，用戶難以接收這樣的轉(zhuǎn)換效率，是XML文件轉(zhuǎn)化時效率的瓶頸。因此，當(dāng)若源文件過大，采用DOM方式不是一個好的選擇。
傳統(tǒng)做法對大文件(如幾十兆或上百兆)的處理一般不直接采用XSLT處理，而采用另外兩種方法一種方法是將數(shù)據(jù)分成塊，通過XSLT分別轉(zhuǎn)換每一塊，最后對結(jié)果塊合并。這樣作編程比較容易，適用性較廣。但是若數(shù)據(jù)過大，分塊過多，這種方法消耗的時間太長，對于大數(shù)據(jù)量GML數(shù)據(jù)處理依然低效。另一種方法是通過編寫一個使用SAX接口的應(yīng)用程序?qū)崿F(xiàn)XSLT樣式表相同的功能。它運行起來速度會比前者快很多倍，效率很高。但基于SAX接口的編程很復(fù)雜，擴展性較差。
目前基于上述技術(shù)方法的常用XSLT處理器主要是Apache公司的Xalan-java處理器(http//xml.apache.org/index.html#xalan，最近訪問時間2004年10月25日)和Michael H.Kay的Saxon處理器(http//www.saxonica.com/，最近訪問時間2004年10月25日)。但是相關(guān)的實驗測試數(shù)據(jù)表明這些XSLT處理器能夠處理的數(shù)據(jù)量如Xalan對于20MB及以上GML文檔無法處理，Saxon對于40MB及以上GML文檔無法處理，即GML文檔過大，處理器轉(zhuǎn)換過程中產(chǎn)生內(nèi)存溢出，導(dǎo)致轉(zhuǎn)換失敗。
故如何設(shè)計一個能高效處理大文檔的XSLT處理器，成為高效地將GML向SVG轉(zhuǎn)換的關(guān)鍵。

發(fā)明內(nèi)容
針對上述問題，本發(fā)明提供了一種不需要將源文件轉(zhuǎn)換為一棵DOM樹的XSLT處理器，避免了生成DOM樹所消耗的時空資源以及內(nèi)存溢出，極大的提高了大數(shù)據(jù)量XML數(shù)據(jù)的轉(zhuǎn)換效率，且適用性較廣新的空間信息發(fā)布樣式表處理器的轉(zhuǎn)換方法。
為了解決上述問題，本發(fā)明處理器的轉(zhuǎn)換方法是對于GML文檔向SVG格式的轉(zhuǎn)換，分別以DOM方式解析樣式表文件，以SAX方式解析源文件。
將上述樣式表劃分為定位信息和結(jié)構(gòu)信息，生成兩棵樣式表樹，在SAX解析器解析源文檔時，每遇到一個元素標(biāo)記就將這兩棵樣式表樹遍歷一遍，若是需要的元素就將數(shù)據(jù)提取出來，如不需要就忽略。
上述具體轉(zhuǎn)換方法是第一步驟對樣式表按照定義分片，并按順序編號；第二步驟將分片按定義劃分為兩類，一類為第一部分(含定位信息)，一類為第二部分(含輸出XML文件的結(jié)構(gòu)信息)；第三步驟將屬于第一部分的分片中的每一片，讀入一個文件流中，每一片對應(yīng)一個文件流，產(chǎn)生一個文件流數(shù)組；第四步驟將屬于第二部分的分片中的每一片，生成一棵DOM樹，產(chǎn)生一個DOM樹數(shù)組，并為每一棵DOM樹分配一個文件流，產(chǎn)生一個文件流數(shù)組；第五步驟當(dāng)SAX解析器解析源文檔時，每遇到一個元素標(biāo)記就將DOM樹數(shù)組中的每一棵DOM樹遍歷一遍，若是需要的元素就將數(shù)據(jù)提取出來，并放入相應(yīng)DOM樹對應(yīng)的文件流中；第六步驟當(dāng)SAX解析器解析源文檔結(jié)束后，將第一部分對應(yīng)的文件流數(shù)組和第二部分對應(yīng)的文件流數(shù)組按第一步驟中的分片順序合并，最后生成的文件流輸出就是結(jié)果文檔。
本發(fā)明的特點是以DOM方式解析樣式表文件，以SAX方式解析源文件。并且將樣式表劃分為定位信息和結(jié)構(gòu)信息，生成兩棵樣式表樹，在SAX解析器解析源文檔時，每遇到一個元素標(biāo)記就將這兩棵樣式表樹遍歷一遍，若是需要的元素就將數(shù)據(jù)提取出來，如不需要就忽略。轉(zhuǎn)換算法能夠快速地實現(xiàn)XML文檔間的轉(zhuǎn)換，并且能夠處理大數(shù)據(jù)量的GML空間信息到SVG的轉(zhuǎn)換。


圖1為本發(fā)明與兩個常用處理器的時間效率對比圖。
圖2為本發(fā)明與兩個常用處理器的空間效率對比圖。
具體實施例方式
下面結(jié)合附圖進一步說明本發(fā)明。
本發(fā)明是將樣式表文件以DOM方式解析為一棵DOM樹存入內(nèi)存中，以SAX方式解析源文件。每遇到一個元素標(biāo)記就將樣式表樹遍歷一遍，若是需要的元素就將數(shù)據(jù)提取出來，如不需要就忽略。
由于在一般情況下，樣式表文件很小，只有幾KB或幾十KB，生成的DOM樹就很小，并且以SAX方式掃描XML文件效率很高，所以本發(fā)明處理器處理速度比一般的XSLT處理器速度要快。尤其當(dāng)源文件數(shù)據(jù)量很大時，一般的XSLT處理器所消耗的時間是以指數(shù)級速度上升，而本發(fā)明處理器在樣式表確定的情況下，所消耗的時間是以線性速度上升的，這是因為SAX方式掃描XML文件所用的時間隨著XML文件大小增加是以線性速度增加的。所以源文件數(shù)據(jù)量越大，一般的XSLT處理器效率下降的越快，并且達到一定數(shù)據(jù)量如4兆左右，一般的XSLT處理器無法處理，而本發(fā)明處理器就不存在這種情況。
為進一步提高XSLT處理器的效率，可以從兩個方面入手一方面提高SAX解析器對XML文檔遍歷的速度，另一方面對樣式表進行優(yōu)化。由于一般對XML編程都是使用實現(xiàn)DOM接口和SAX接口的軟件包提供的API，如Aparche公司提供的Xerces包，IBM公司的DOM4J包，SUN公司的JDOM等產(chǎn)品。一般的XSLT處理器都是以這樣的一些產(chǎn)品為開發(fā)平臺作二次開發(fā)，如應(yīng)用相當(dāng)廣泛的XSLT處理器——Xalan處理器就是基于Xerces包開發(fā)出來的。這些軟件包對于SAX接口的支持和SAX解析器的執(zhí)行效率雖然略有不同，但差距不大。所以，通過提高SAX解析器對XML文檔遍歷的速度來提高XSLT處理器的執(zhí)行效率不是一種有效的方法。
本發(fā)明處理器在作轉(zhuǎn)換時，當(dāng)通過SAX解析器遍歷源文件時，每遇到一個元素標(biāo)記就將樣式表樹遍歷一遍，故樣式表樹的大小對本發(fā)明處理器的執(zhí)行效率有相當(dāng)大的影響。尤其當(dāng)源文件相當(dāng)大時，即源文件的元素相當(dāng)多，如十萬或幾十萬個元素(也許這對傳統(tǒng)的XML應(yīng)用中的XML文檔來說這種情況相當(dāng)少見，如電子商務(wù)中的XML數(shù)據(jù)一般只有幾十個或幾百個元素，這對于GML文檔來說是相當(dāng)常見的)，若樣式表樹能在不影響它的功能的情況下有效的縮小，則本發(fā)明的執(zhí)行效率會得到極大提高。對樣式表進行優(yōu)化是提高本發(fā)明處理器執(zhí)行效率的一種有效方法，本發(fā)明通過對樣式表的結(jié)構(gòu)進行分析，設(shè)計了一種樣式表轉(zhuǎn)換方法。
樣式表文件由兩部分組成，第一部分是對源文件相應(yīng)數(shù)據(jù)的定位信息，即由XSL規(guī)范所定義的有從源文件定位數(shù)據(jù)功能的標(biāo)記(如xslfor-each、xslvariable、xslcopy-of、xslvalue-of等)所構(gòu)成的節(jié)點，以及包含在這些節(jié)點中的非XSL規(guī)范所定義的元素。第二部分是輸出XML文件的結(jié)構(gòu)信息，不符合前一部分要求的并且屬于結(jié)果文檔標(biāo)記的所有元素。兩部分在整個XSLT處理過程中起不同作用，樣式表的第二部分只與結(jié)果文檔有關(guān)，與源文檔無關(guān)；樣式表的第一部分因為有數(shù)據(jù)定位的功能所以與源文檔密切相關(guān)。本發(fā)明處理器時空消耗最大的部分，在于以SAX方式解析源文檔，并通過樣式表的數(shù)據(jù)定位功能提取數(shù)據(jù)的過程。在這個過程中樣式表樹越小效率越高，而整個樣式表中真正參與到這個過程當(dāng)中的只有第一部分，第二部分完全與之無關(guān)。所以沒有必要將整個樣式表轉(zhuǎn)化為樣式表樹，只需要將第一部分轉(zhuǎn)換為樹參與此過程即可。所以，本發(fā)明將樣式表生成兩棵樣式表樹，在SAX解析器解析源文檔時，每遇到一個元素標(biāo)記就將這兩棵樣式表樹遍歷一遍。
為了測試本發(fā)明的性能，我們選取了1MB-50MB之間的14組GML空間數(shù)據(jù)，采用相同的樣式表，在相同的機器上，分別用目前最常用的XSLT處理器--Apache公司的Xalan-java處理器、Michael H.Kay的Saxon處理器與本發(fā)明做對比實驗。表1是對三個處理器的測試數(shù)據(jù)和測試結(jié)果，一共14組數(shù)據(jù)。表1中Method列中Xalan表示Xalan-java處理器，Saxon表示Saxon處理器，Name列表示圖層名；GML、XSL、SVG列分別表示GML、XSL、SVG文件的大小；TotalTime列表示GML文檔轉(zhuǎn)換為SVG圖所消耗的時間，單位為ms；Memory列表示GML文檔轉(zhuǎn)換為SVG圖所消耗的內(nèi)存，單位為MB。
表1


從表1可以看出，在Xalan和Saxon實驗結(jié)果中的SVG列中有若干項為零(如Xalan對于20M及以上GML文檔無法處理，Saxon對于40M及以上GML文檔無法處理)，表示GML文檔過大，使用處理器會產(chǎn)生內(nèi)存溢出，導(dǎo)致轉(zhuǎn)換失敗。而本發(fā)明處理器不存在這樣的問題。圖1是三個處理器對14組測試數(shù)據(jù)轉(zhuǎn)換所耗時間的曲線圖。縱坐標(biāo)表示時間，單位為ms；橫坐標(biāo)表示GML文檔大小，單位為MB。圖2是三個處理器對14組測試數(shù)據(jù)轉(zhuǎn)換所耗內(nèi)存的曲線圖。縱坐標(biāo)表示所耗內(nèi)存，單位為MB；橫坐標(biāo)表示GML文檔大小，單位為MB。兩個圖中最下面的一條線表示本發(fā)明處理器的執(zhí)行結(jié)果；圖1中間的一條線、圖2上面的一條線表示Saxon處理器執(zhí)行結(jié)果；圖1上面的一條線、圖2中間的一條線表示Xalan處理器執(zhí)行結(jié)果。從圖中可以看出本發(fā)明處理器的時間效率和空間效率都比Xalan處理器和Saxon處理器好，而且對于10M以上的大文檔本發(fā)明所耗的內(nèi)存基本上呈線性增長。
本說明書中未作詳細描述的內(nèi)容屬于本領(lǐng)域?qū)I(yè)技術(shù)人員公知的現(xiàn)有技術(shù)。
權(quán)利要求
1.一種新的空間信息發(fā)布樣式表處理器的轉(zhuǎn)換方法，其特征在于對于GML文檔向SVG格式的轉(zhuǎn)換，分別以DOM方式解析樣式表文件，以SAX方式解析源文件。
2.如權(quán)利要求1所述的新的空間信息發(fā)布樣式表處理器的轉(zhuǎn)換方法，其特征在于將樣式表劃分為定位信息和結(jié)構(gòu)信息，生成兩棵樣式表樹，在SAX解析器解析源文檔時，每遇到一個元素標(biāo)記就將這兩棵樣式表樹遍歷一遍，若是需要的元素就將數(shù)據(jù)提取出來，如不需要就忽略。
3.如權(quán)利要求1或2所述的新的空間信息發(fā)布樣式表處理器的轉(zhuǎn)換方法，其特征在于第一步驟對樣式表按照定義分片，并按順序編號；第二步驟將分片按定義劃分為兩類，一類為第一部分(含定位信息)，一類為第二部分(含輸出XML文件的結(jié)構(gòu)信息)；第三步驟將屬于第一部分的分片中的每一片，讀入一個文件流中，每一片對應(yīng)一個文件流，產(chǎn)生一個文件流數(shù)組；第四步驟將屬于第二部分的分片中的每一片，生成一棵DOM樹，產(chǎn)生一個DOM樹數(shù)組，并為每一棵DOM樹分配一個文件流，產(chǎn)生一個文件流數(shù)組；第五步驟當(dāng)SAX解析器解析源文檔時，每遇到一個元素標(biāo)記就將DOM樹數(shù)組中的每一棵DOM樹遍歷一遍，若是需要的元素就將數(shù)據(jù)提取出來，并放入相應(yīng)DOM樹對應(yīng)的文件流中；第六步驟當(dāng)SAX解析器解析源文檔結(jié)束后，將第一部分對應(yīng)的文件流數(shù)組和第二部分對應(yīng)的文件流數(shù)組按第一步驟中的分片順序合并，最后生成的文件流輸出就是結(jié)果文檔。
全文摘要
本發(fā)明涉及一種新的空間信息發(fā)布樣式表處理器的轉(zhuǎn)換方法。本發(fā)明以DOM方式解析GML樣式表文件，以SAX方式解析GML源文件，并且將樣式表劃分為定位信息和結(jié)構(gòu)信息，生成兩棵樣式表樹。在SAX解析器解析源文檔時，每遇到一個元素標(biāo)記就將這兩棵樣式表樹遍歷一遍，若是需要的元素就將數(shù)據(jù)提取出來，如不需要就忽略。本發(fā)明的特點是能夠快速地實現(xiàn)XML文檔間的轉(zhuǎn)換，并且能夠處理大數(shù)據(jù)量的GML空間信息到SVG的轉(zhuǎn)換，實現(xiàn)空間信息的發(fā)布。
文檔編號G06F17/30GK1614592SQ20041006118
公開日2005年5月11日 申請日期2004年11月25日 優(yōu)先權(quán)日2004年11月25日
發(fā)明者關(guān)佶紅, 周水庚, 邊馥苓, 陳俊鵬, 張俊, 張建華 申請人:武漢大學(xué)