前言

在上期中，我們介紹了XML伺服器的架構，包括架構的說明，架構中各元件所擔負的任務，以及運作的流程等等。在這一期中，我們要介紹的是在XML資料上所使用的查詢語言。當XML成為資料交換的標準之後，XML的資料數量將會大量增加，屆時對XML查詢的需求將會不可或缺。本文就針對XML上所使用的查詢語言，也就是XQL，為各位做一個完整的介紹。

為什麼要查詢XML?

這個問題很簡單，由於我們在前一期探討過XML伺服器的架構，因此可以想見的是，XML文件一旦用一個伺服架構來進行管理之後，就會遇到傳統上資料庫的共通問題，也就是所謂的資料庫查詢標準。在過去，我們對於關聯式資料庫或是物件導向資料庫的查詢處理，都是透過一個結構化的查詢語言來進行，也就是SQL或是OQL(Object Query Language)，這種查詢語言允許你針對特定的資料表或是物件樹進行查詢操作，並允許你以特定的過濾標準來篩選資料。而在文件庫的查詢上，則是採用了非結構性的查詢標準，也就是我們所熟知的全文檢索，這種查詢方法完全不去限定特定的資料範圍，並利用特殊的索引方法來加速查詢的處理，如反向索引(inverted index)或是特徵檔案(signature file)等等。而對於XML這種特殊結構的資料文件型態，則必須發展出另一種查詢的方法，因為其特性的關係，傳統的查詢處理已不再適用。以下我們就針對XML的特性，來介紹XML上的查詢標準。

XML上的查詢標準：XQL

所謂XML文件，就是一種結構化的文件，它將資料(data)與文件(document)之間的界線拉近並使之模糊，也就是允許將文件當程式資料的來源端，同時傳統的資料來源端也被當成式文件型態來進行處理。有部分的XML文件相當簡單，就如同傳統資料庫的文字資料而已，但有部分的XML中則包含了關聯式表格所無法處理的資料結構。在我們傳統上會處理的資料，有時也可以透過XML來發揮其影響力。舉例來說，醫院的醫療紀錄在經過XML標記之後，就可以當成相當有用的資料來源端，它可以提供各種不同型態的醫療資料，包括病歷、診斷、處方、以及帳款等等。

當有越來越多的資料是以XML文件的型態儲存時，以XML來交換資料、呈現多樣性資料的用途就會陸續出現。因此，不可避免地就會遇到下一個問題：要有一個有效的處理機制，用來查詢XML的資料來源端，也就是說，當XML成為一個通用的交換標準之後，就需要有一個通用的查詢標準來存取相關的資料。使用XML的查詢，將有助於在大量的資料集中依照不同的標準，來進行資料的篩選以及邏輯觀點(view)的建立。因此，在XML上的查詢標準，我們就以XQL(XML Query Language)來稱呼它。

XQL是設計用來處理一般性的XML資料，而在設計的過程中，XML的相關需求則是由四個主要的需求領域(problem domain)來決定。這些需求領域列舉如下：

1. 在單一XML文件中的查詢需求(如XML瀏覽器或是XML編輯器中)。

2. 在文件集之中的查詢需求(如XML文件所形成的資料儲存端)。

3. 文件之中的連結，以及文件之中的連結(如XLI和XPointers)。

4. XSL樣式的查詢需求。

以上這四個需求領域，都各具特色，而領域之間的相似性也相當的低。同時在這裡所謂的查詢也和傳統我們對查詢的定義有所不同。例如XPointers是針對特定文件指定某個定點，而XSL則是用來處理XML文件的特定元素(element)。由於特性差異甚大，傳統上使用SGML以及XML的開發者都會將這些領域分開處理。即使在這些領域之間有著很大的差異性，但這些處理工作上也存在著一定的共通性。也就是說，在處理上對不同領域的處理方法自然不同，但在其中查詢層次的需求卻是相當地類似。

這點對應回傳統的SQL之於關聯式資料庫上，有著相當類似的特性。SQL在關聯式資料庫上的用途相當地多，也相當的不同，如建立資料觀點，執行查詢，指定資料記錄等等。即便如此，在其上運作的查詢語言，也就是SQL，卻是相同的。因此，即使在XML的需求領域上有著不同的差異，其上的查詢語言，也就是XQL，是可以以相同的設計概念來進行。接下來，我們就針對這些不同的需求領域，來探討這些領域的需求，並透過這些需求來進行一個多用途查詢語言的設計。

1.在單一XML文件中的查詢：

這種查詢對於在XML瀏覽器或是XML編輯器中的文件特別有用，這樣的查詢允許使用者查詢一個大型的文件，卻不需要上下捲動來找尋所需要的相關資料。此外，文件的作者也可以利用這樣的查詢來建立對文件的不同觀點，如此一來，便可以針對不同知識背景的使用者，為其建立適合使用者閱覽的文件內容，甚至可以利用這樣的方法，來限制不同權限使用者可以閱覽的內容範圍。在這樣的需求領域下，所謂的資料輸入端，就是一個完整的XML文件，而對這個文件的載入處理上，可以相當的簡單，也可以相當的複雜。

簡單的處理方式就是載入整份文件到記憶體中，但是複雜的處理方式則包括考慮記憶體的使用量，或是只載入部份的文件內容，甚或是針對文件建立索引等等。而查詢處理後的結果則有著各種不同的表現形式。例如，查詢結果可以是針對文件中特定節點的列舉列表，或是一個可以顯示文件特定位置的列表，甚至可以是一個動態建立並可供瀏覽的樹狀結構。雖然查詢結果可能有著很大的不同，但對查詢語言的角色來說，都是不變的，也就是說，查詢的目的都是要取出一個集合的節點，至於表現的形式則是另一個步驟。至於查詢所得到的資料，應該包含以下幾種：

A. 元素(element)或是屬性(attribute)的名稱。

B. 節點的型態(如元素、屬性、處理指令，以及位置等等)。

C. 節點的內容或其資料值。

D. 節點與節點之間的關係，包括階層、順序，以及位置等等。

在文件集之中的查詢：這種查詢的用途相當廣泛，包括由文件所組成的XML文件儲存端，抑或是單一或是跨網站的查詢，甚至是資料發掘(data mining)。這樣的查詢是以一個XML文件集或是多個文件之中的節點集合為基礎。而其查詢結果的輸出，則可以和查詢單一文件的輸出相同。

2.文件之中以及文件之間的連結：

這種查詢特別是用來處理文件中使用超連結所指定的位址，曾使用過瀏覽器的人都知道，HTML中所提供的超連結就是將特定的文件以URL名稱來表示，以達到利用文件的錨點(anchor)來直接連結標的文件的目的，而標的文件的名稱就是以屬性的型態來予以定義。一個單一的Web文件可以包括指向別處的文件連結，也可已是文件本身其他位置的連結。而在XML以及SGML的世界裡，長久以來就有比這樣的連結型態還要複雜的特性，包括TEI連結、HyTime連結，以及XML的連結。這些連結都允許更大彈性的連結型態，其中包括：

A. 指定文件中的任何節點，而不須對節點做任何的指定與更改。

B. 對已知的文件位置指定相對路徑。

C. 在一個文件樹中指定絕對路徑。

3.XSL樣式：

由於XSL樣式適用來指定文件中結構樹與其他結構樹之間的轉換對應關係，所以這樣的查詢比起前三種查詢來說，又有著截然不同的形式。在這樣的轉換過程中，我們會看到一個相當重要的環節，就是根據個別節點的屬性以及其相關節點的屬性來作測試，因此對於節點查詢的需求就顯現於此。對XSL的轉換來說，輸出的結果是另一個樹狀結構的資料，而轉換的過程則是根據XSL中所定義的樣板規則來決定。因此，由XSL樣式所指定對節點的測試來看，和我們先前所提對文件查詢的標準是相同的，列舉如下：

A. 元素(element)或是屬性(attribute)的名稱。

B. 節點的型態(如元素、屬性、處理指令，以及位置等等)。

C. 節點的內容或其資料值。

D. 節點與節點之間的關係，包括階層、順序，以及位置等等。

由上面四點來看，XQL查詢的需求領域的確有相當的差異，其中包括輸入、輸出、處理模型、以及處理結果的輸出形式等等。但無論如何，它們都有一個相同點，就是它們都必須根據某些特定的宣告來指定一個或多個節點，這樣的宣告包括節點名稱、內容、內含值、以及和其他節點之間的關連。而XQL正提供了指定這些特定宣告的途徑。又由於XQL並不去指定所需要的輸入格式、輸出格式、以及處理模型，因此它對於這幾的查詢形式存在：個需求領域來說，是完全中性的。這也就是為什麼XQL可以像傳統的SQL角色如此重要一般。

XQL的使用環境

當我們檢視過XQL的需求領域之後，接下來我們就來看看可能使用到XQL的幾種環境。由於Web環境相當的普及，因此我們也必須讓XQL這樣的查詢語言可以在多樣性的Web環境中使用，因此我們先將幾種可能的使用環境歸納如下：

1.以命令列的查詢形式存在：

這種單純的查詢字串是所有XQL查詢最基本的表示形式。它可以由命令列直接下達，也可以透過圖形化的查詢界面來產生，甚至可以放在程式中來執行。舉例來說，以下是一個查出author元素中所有front元素的XQL查詢：

author/front

這樣的查詢會將所有的author元素予以檢視，而檢視的標準則在於是否有front元素的存在，如果有的話，則將符合的元素以結構樹的方式傳回。

2.在程式語言中指定：

在一個程式語言中，XQL可以被指定成字串形式，並當成一種可執行的查詢。舉例來說，以下是一個以Java字串形式存在的XQL查詢：

String qstring = "front/author";

3.以URL的形式存在：

XQL查詢不但可以由以上的形式存在，同時也可以成為URL的一部份，用以提供更仔細過濾後的文件。舉例來說，以下便是一個包含XQL查詢的URL:

http://www.example.com.tw/documents#front/author

4.以HTML或XML中的屬性存在：

XQL查詢也可以在HTML或是XML文件中存在，其形式就是以屬性值(attribute)的形式表示，如下所示︰

＜a href=* http://www.example.com.tw/documents#front/author"＞

XQL查詢的內涵

要了解XQL查詢的內涵，我們可以藉由和傳統的SQL語言比較，來一窺究竟。比較的層面可以分為四個主要的部份：由資料儲存的角度來看(也就是資料庫)、由查詢語言的角度來看、由查詢的輸入端來看、以及由查詢的結果來看。而其比較的結果則由下表來表示：

如果要更清楚地了解這些概念，我們可以透過一個最簡單的範例來檢視所謂的搜尋主體(資料)、查詢、以及查詢的結果。在下例中，我們透過查詢novel元素，來針對搜尋主體進行處理：

以上的例子相當簡單，只是一個單一節點的範例，往後我們還會有更複雜的資料與查詢範例供讀者參考。

查詢結果的形式

在(表一)中，我們可以清楚的知道，SQL的查詢結果是由一個表格的記錄所形成的，這也就是說，SQL查詢的結果會是一個原表格資料的子集合，並由一筆一筆選出的欄位記錄所構成。那麼，XQL查詢的結果呢？在上例中(圖一)，我們知道XQL查詢所產生的結果也是以一個XML文件結構存在的形式。為什麼是以這樣的形式存在呢？在以下的敘述中，我將會發現，在許多不同的使用環境中，XQL的結果大多是以XML文件的形式存在最為恰當，理由如下：

《表一　SQL與XQL特性的比較表》

《圖一　一個簡單的查詢範例》

1. XML文件可以很輕易的使用一個標準的XML parser來予以解析，因此XQL查詢所產生的XML文件以ASCII 資料流來傳遞是在簡單也不過的事情了。

2. XML文件可以在一個支援XML的瀏覽器中呈現，因此呈現部份的工作不需要由應用程式來負擔。

3. XML文件可以很輕易的存放在XML儲存端中，請參考上期中我們所介紹的XML伺服器架構，一旦有了這樣的伺服架構，我們就不必再去費心構思XQL查詢結果的儲存問題。

4. XML文件可以透過XSL處理器的處理來作某些形式的轉換，以提供多樣性的呈現，或是不同應用程式之間的資料交換用途。

在(圖一)中，我們所看到的查詢結果，僅是一個單一節點所形成的XML文件，但是如果XQL查詢包含了一個以上的節點的話，要維持一個結構良好的XML文件(也就是只允許單一根節點存在的XML文件)結構，就必須要做一些必要的加工。針對這樣的問題，我們可以用以下的例子來解釋。在下面的XQL查詢中，我們使用了一個 “*” 的查詢運算符號，這種查詢運算是要取出所有符合的元素，而不管元素的名稱為何。而 “/” 符號則代表了節點之間的直接從屬關係(parent/child)，請見(圖二)：

《圖二　一個進階的查詢範例》

後記

本文說明了XQL的設計精神，以及XQL在許多方面的設計考量。在下一期中，我們將會深入介紹XQL的語法，以及各種XQL語法的用途與相關的範例。