在本系列的前面三篇文章中，我論述了 XML/RDF 詞匯表 DOAP 的開發，DOAP 用於描述開發源代碼項目以及相關的一些資源。通過使用 DOAP，軟件維護人員不再需要在多個 Web 站點注冊他們的程序。相反，他們可以簡單地給出 DOAP 描述的 URL。隨著更多的應用程序成為 DOAP 感知的應用程序，參與和管理開放源代碼項目開啟了新的可能性。
為達到這些目標，除了創建詞匯表外，還要做更多的事情，這一點很重要。在這篇總結性的文章中，我從文檔、工具和社區這幾個方面考察了采用 DOAP 所需要的一些東西。
查看 DOAP
為了喚起您的記憶，這裡有一個簡單的 DOAP 文件 -- 清單 1 展示了用於 DOAP 項目本身的一個很小的 DOAP 文件。
清單 1. DOAP 項目本身的簡單 DOAP 描述
<Project XMLns="http://usefulinc.com/ns/doap#"
XMLns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:foaf="http://XMLns.com/foaf/0.1/">
<name>DOAP</name>
<homepage rdf:resource="http://usefulinc.com/doap" />
<created>2004-05-04</created>
<shortdesc XML:lang="en">
Tools and vocabulary for describing community-based
software projects.
</shortdesc>
<description XML:lang="en">
DOAP (Description of a Project) is an RDF vocabulary and
associated set of tools for describing community-based software
projects. It is intended to be an interchange vocabulary for
software directory sites, and to allow the decentralized
expression of involvement in a project.
</description>
<maintainer>
<foaf:Person>
<foaf:name>Edd Dumbill</foaf:name>
<foaf:homepage rdf:resource="http://usefulinc.com/edd" />
</foaf:Person>
</maintainer>
</Project>
DOAP 用戶的最先需求也是最基本的需求是，獲得該數據的一個用戶友好的視圖。如果不存在其他的編輯機制，那麼可以手工編輯一個文件，然後使用查看器檢查該文件 -- 很多 Web 站點都采用這種古老而又公認有問題的方法創建。創建查看器最快捷的方法可能是編寫一個 XSLT 樣式表，以便將傳入的 RDF/XML 轉換成 Html。
然而，DOAP 不僅僅是一個 XML 詞匯表，也就是說，使用 XSLT 並不是一個簡單的決定。查看器可以用於不止一個目的：它不僅提供對 DOAP 數據的查看，而且還是 DOAP 處理應用程序的第一個例子。於是，很多第一次接觸 DOAP 的實現者都拿它作為一個例子。因此，如果 DOAP 查看器是一個 RDF 感知的應用程序，那麼它就很有幫助。
為了創建一個查看器，我使用 Redland RDF Application 庫將 DOAP 文件讀到一個駐留在內存中的 RDF 存儲中，並從該存儲中提取數據到 XML 中，然後用 XSLT 格式化該 XML。這種中間 XML 表示可以轉換成服務器端應用程序上的 HTML，或者可以用來驅動客戶端 DOAP 查看器的圖形用戶界面。圖 1 展示了來自查看器的經過轉換的 Html 輸出。
圖 1. 轉換後的 DOAP 輸出
為了創建該查看器，我使用來自 Redland 的 Mono/.Net 綁定（請參閱 參考資料）。清單 2 中的代碼片斷展示了一個循環，該循環用於處理 DOAP 文件中的每個項目（通常只有一個項目），並輸出 XML 文檔中由 <project> 元素括起來的數據。 rdf ["type"] 和 doap ["Project"] 變量是具有 URI 的資源節點的快捷方式，分別對應於 RDF 和 DOAP 模式中的術語。
清單 2. 用於從 DOAP 文件中提取項目的 Redland C# 代碼片斷
foreach (Node proj in model.GetSources (rdf ["type"], doap ["Project"])) {
w.WriteStartElement (null, "project", null);
Node name = model.GetTarget (proj, doap ["name"]);
w.WriteStartElement ("name");
w.WriteString (name.Literal);
w.WriteEndElement ();
...
w.WriteEndElement ();
}
編寫 DOAP 查看器的另一個有趣的選項是，使用 Mozilla Web 浏覽器中的 RDF 呈現支持，並創建一個基於 XUL 的 DOAP 查看器。這種方法可能導致一種在浏覽器中擴展的設想，例如 Firefox。
驗證 DOAP
驗證 DOAP 文件的能力是處理這些文件時必不可少的一部分。不管 DOAP 的創建還是使用，驗證都是有用的。對於創建者，不管他們是手工編寫 DOAP 還是通過創建工具輸出 DOAP，驗證程序（validator）都會保持與規范的一致性。對於 DOAP 的消費者，必需進行驗證，確保軟件不去處理無用的數據。
最基本的驗證只是對輸入文件是否滿足規范這類問題報告 "yes" 或者 "no" 的過程。更有幫助的驗證程序可以報告錯誤並給出建議。也許最著名的驗證程序是 W3C Html Validator （請參閱 參考資料），它可以返回各種幫助信息，以改善 Web 站點與 W3C 規范的一致性。
因為 DOAP 是 RDF/XML，所以我們可以在各種級別上對它進行驗證：
XML： DOAP 必須是格式良好的 XML。
RDF： DOAP 必須是合法的 RDF。
語義： 要使文檔有意義，文檔必須包含足夠的 DOAP 術語。例如，一個 DOAP 文件如果沒有名稱、描述和主頁屬性，那麼根本沒用。
傳統上，純 XML 驗證技術只達到了對 語法的驗證 -- 即元素和屬性的存在或不存在，以及它們的順序。雖然這種驗證能捕獲很多錯誤，但是對於需要進行數據處理以判斷是否編寫了不合情理而語法正確的內容這樣的場景，這種驗證就毫無幫助了。然而，某些語義約束可以表達為語法約束。例如，一條 DOAP 需求說，必須有一個 "homepage" 屬性，那麼您可以用一個 XML 模式來捕獲那些錯誤。
使用 XML 模式驗證 RDF 的問題是，RDF 有非常靈活的 XML 語法，在編寫同樣的東西時可以有多種方法。實際上，用 W3C XML Schema 來驗證 RDF 是不可能的。而通過一個 RDF 解析器（例如 Redland 的 raptor）來運行 RDF，以檢查其 RDF 合法性，這種方法要更容易一些。如果知道一個傳入的 DOAP 文件是合法的 RDF，那麼就可以應用一系列的語義測試來判斷該文件其余部分的質量。
只要每個人都可以使用 RDF 處理工具，或者只要您願意提供免費的 Web 服務來驗證 DOAP，這種策略就可以用得很好。不過，您可以犧牲 RDF 的一些語法靈活性，以便通過提供一個 XML 模式來獲得更大的普遍性，這個 XML 模式完成驗證過程的前面 70%，並使用語法方法驗證一定數量的語義完整性。這樣，再加上一點常識，便足以滿足很多人的要求了。
按照以上幾條，我為 DOAP 的受限 RDF/XML 語法版本構造了一個 RELAX NG 模式。注意，該模式不會驗證所有的 DOAP 文件，但是它所驗證的文件肯定是 DOAP 應用程序可以處理的。清單 3 展示了 RELAX NG Compact 符號中的模式。
清單 3. 用於 DOAP 的受限 XML 配置文件的 RELAX NG 模式
default namespace = "http://usefulinc.com/ns/doap#"
namespace foaf = "http://XMLns.com/foaf/0.1/"
namespace rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
namespace rdfs = "http://www.w3.org/2000/01/rdf-schema#"
grammar {
rdf-resource = attribute rdf:resource { text }
xml-lang = attribute XML:lang { text }
literal = XML-lang?, text
Person-element = element foaf:Person {
element foaf:name { literal }
& (
element foaf:homepage { rdf-resource } |
element foaf:mbox { rdf-resource } |
element foaf:mbox_sha1sum { text }
)+&
element rdfs:seeAlso { rdf-resource}*
}
cvs-repository = element CVSRepository {
element anon-root { text },
element module { text },
element browse { rdf-resource}?
}
svn-repository = element SVNRepository {
element location { rdf-resource },
element browse { rdf-resource}?
}
bk-repository = element BKRepository {
element location { rdf-resource },
element module { text },
element browse { rdf-resource}?
}
arch-repository = element ArchRepository {
element location { rdf-resource },
element module { text },
element browse { rdf-resource}?
}
start = element Project
{
element name { literal }&
element homepage { rdf-resource }&
element old-homepage { rdf-resource }*&
element created { text }&
element shortdesc { literal }+&
element description { literal }+&
element mailing-list { rdf-resource }*&
element maintainer { Person-element }+&
element developer { Person-element }*&
element documenter { Person-element }*&
element translator { Person-element }*&
element tester { Person-element }*&
element helper { Person-element }*&
element category { rdf-resource }*&
element release {
element Version {
element name { text },
element created { text },
element revision { text }
}
}*&
element license { rdf-resource }*&
element download-page { rdf-resource }?&
element download-mirror { rdf-resource }*&
element repository { ( cvs-repository | svn-repository
| bk-repository | arch-repository ) }*&
element bug-database { rdf-resource }?&
element screenshots { rdf-resource }*&
element wiki { rdf-resource }*&
element programming-language { text }*&
element os { text }*
}
}
構造該模式的一個非常好用的副產品是，現在可以使用 XML 編輯工具來編寫合法的 DOAP 文件。圖 2 展示了 Emacs文本編輯器的 James Clark 的 nxml 模式（mode），EMacs 文本編輯器用於編輯 DOAP 本身的 DOAP 描述。 nXML 模式（mode）使用 RELAX NG Compact 模式。注意打了下劃線的有效性錯誤。在手工編輯（hand-authoring）級別上，失去語法的部分表達能力和獲得編輯工具支持之間的折衷是值得的。
圖 2. 以 nXML 模式（mode）編輯 DOAP 文件的 EMacs
通過使用模式進行驗證，可以同時確保 XML 的格式良好性和一定的語義完整性。然而，這是不夠的，我們還必須求助於 RDF 處理來執行驗證過程剩下的步驟。這些步驟可能包括檢查給出的許可 URI 以便發現 DOAP 工具是否承認它們，在適當的地方對文本進行拼寫檢查，等等。
我已經開始了關於基於以上幾條的驗證程序的工作，該驗證程序以類似於查看器應用程序的方式給出 XML 輸出。這樣一來，驗證程序代碼便可同時用於 Web GUI 應用程序和客戶端 GUI 應用程序。驗證程序執行四種級別的檢查：
XML 格式良好性。
基於 RELAX NG 模式的有效性（可以選擇禁用該選項）。
RDF 有效性。
一系列特定於 DOAP 的語義檢查。
清單 4 展示了驗證程序的兩次示例運行情況，其中捕獲了 XML 格式良好性和語法有效性錯誤。其意思是可以使用來自 <Test> 元素的測試名稱作為對進一步的、更詳細的解釋和建議的索引。
清單 4. 驗證程序輸出
<Problems>
<Problem>
<Test>ParseXML</Test>
<Title>Not well-formed XML</Title>
<Description>DOAP files must follow the rules of XML syntax.</Description>
<Detail>unmatched closing element: expected name but found Project Line
27, position 10.</Detail>
</Problem>
</Problems>
<Problems>
<Problem>
<Test>Doap.Tests.XML.RelaxValidate</Test>
<Title>XML syntax validation</Title>
<Description>This test checks to see that the DOAP file validates against
a restricted XML syntax, which guarantees its validity.</Description>
<Detail>Invalid start tag found. LocalName = Person, NS =
http://XMLns.com/foaf/0.1/. line 26, column 3</Detail>
</Problem>
</Problems>
您可以在 DOAP 主頁獲得該驗證程序的代碼（請參閱 參考資料）。在 Web 上將建立一個公共訪問實例。應確保 DOAP 的采納者能夠在較早的階段檢查它們的輸出，這一點很重要。此外，我建議，所有 DOAP 處理應用程序都首先驗證它們的輸入 -- 至少要用 RELAX NG 模式 -- 以使 Web 上 DOAP 內容的質量出現最少的異常。只需簡單地看看對 Web 上 RSS feed 的松散解析所帶來的混亂，就足以讓您相信一定程度的嚴格性是有益的。為提供幫助，驗證程序和查看器的代碼將獲得一個寬松的開放源代碼許可，以便能夠放心地將它們集成到其他程序中。
創建 DOAP
如何首先創建 DOAP 文件呢？最初的采納者將在一個文本編輯器中手工編寫該文件。而驗證程序和 XML 模式文件則一起幫助確保那些文件不包含錯誤。如前所述，遵從模式的 DOAP 文件將失去一些 RDF 表達能力，但是對於大多數人來講，這點損失關系不大。
大多數創建 DOAP 文件的人對 DOAP 詞匯表本身不感興趣。他們只是想要最終的功能，同時允許他們通過軟件注冊來注冊他們的項目。他們很可能會找到一個例子文件，然後通過修改使其包括他們自己的數據。由於這個原因，關鍵是確保能提供足夠的教學材料、好的例子以及驗證工具，使不好的例子不至於蔓延。一旦糟糕的剪切-粘貼版本傳了出去，其蔓延之勢便難於阻止了。
DOAP 創建過程的剪切-粘貼階段應該盡可能地短。您可以通過引入對 DOAP 文件創建的一定程度的工具支持來做到這一點。大多數軟件開發人員已經在使用某些打包和配置系統，這些系統至少包含為軟件生成 DAOP 文件時所需的部分元數據。這樣的系統包括用於 C 語言編程的 GNU Autoconf、Python distutils、Perl 的 MakeMaker文件等等。如果對於開發人員所選擇的系統有一個容易的 DOAP 生成方案，那麼就可以增加獲得 DOAP 文件權利的機會。
此外，您可以使用不同的創建 DOAP 文件的有向導的方法：
DOAP-a-matic： Leigh Dodds 的 FOAF-a-matic 是一種支持 JavaScript 的 Web 頁面，它使得 FOAF（Friend-of-a-frIEnd）文件的創建變得容易。其 DOAP 版本很有用，所以開發人員只需回答一些問題。
Freshmeat-to-DOAP 轉換：Freshmeat 軟件注冊或許是在周圍最大的，它提供了 Freshmeat 內容的 XML 輸出。編寫一個從 Freshmeat 內容生成 DOAP 描述的程序將變得相當容易。
GUI 應用程序：圖形應用程序可以集成到一個 IDE（例如 Eclipse 或 MonoDevelop）中，並將 DOAP 所需的元數據與項目的構建信息存儲在一起。然後，DOAP 文件就成了最終的 build 的一部分。
這裡雖然創建了 DOAP，但應該達到兩個重要的目標，即 DOAP 應該盡可能易於開發人員使用，並且其創建的輸出應盡可能的豐富和高質量。可用數據的普遍性和質量都是 DOAP 前景的關鍵所在。
社區
即使有了工具，如果沒有集結在 DOAP 項目周圍的社區，那麼它也不大可能長久。引入新技術時，溝通是至高無上的。像約定的規則一樣清晰地表達項目的目標，這一點很重要。溝通中最基本的步驟是構造一個 Web 站點，該 Web 站點應包含所有相關文檔，並指向在項目中可以使用的那些相關資源。
圖 3 展示了 DOAP 主頁的一個屏幕快照。注意兩個重要特征：清楚的導航和新聞。靜態 Web 站點常常給人以沉悶的印象，而定時地更新新聞則可以滿足通知人們和使項目看上去生動的雙重需要。現今，為項目新聞使用 RSS feed 也是必要的。
圖 3. DOAP 主頁的屏幕快照
雖然沒有必要一開始就回答所有可以想像到的問題，但是項目 Web 站點需要在添加文檔和教程材料方面的反應盡可能地迅速。 How-to 問題以及 FAQ 常常出現在新采納者第一眼就可以看到的地方。
然而，溝通不會總是單方向的。我們需要有一個論壇，讓那些有興趣使用和采納 DOAP 的人能夠互相碰面並問一些問題。對於開放源代碼項目，郵件列表曾經是最成功的實現這一點的媒介，而 DOAP 也確實有這樣的東西（請參閱 參考資料）。 隨著社區的增長，使用 DOAP 的第三方可以在那裡宣布他們自己的產品和成就，以促進他們的產品或成就被采納並得到進一步的發展。
最後，必須向那些可能感興趣的人展示項目，使得項目植根於群眾。除了在 XML 會議上展示 DOAP 以外，我還將在各種郵件列表中宣傳它，並向開放源代碼領域內的一些關鍵人物作宣傳。
結束語
雖然本文是關於 DOAP 的創建的系列文章（分為 4 個部分）中的最後一篇，但它也標志著公眾眼裡項目生命周期的開始。我相信，DOAP 在利用 Web 技術語義上的威力，和保留足夠的 "Webby" 以獲得大規模的支持這兩者之間將達到一個適當的平衡。幾個月之後，我將在本專欄中回訪這個項目，看看這些決定在中長期內表現如何。