LAST UPDATE: Aug 2010

The aim of the tool is to validate a specific format of metadata that gives a uniform representation of our national resources, which are sponsored by the national program, Taiwan e-Learning & Digital Archives Program. The metadata is based on XML technology. They should meet not only the basic rules of a well-formed XML document but also additional specifications set by the national program. Specifically, the tool would check three parts of the metadata: 1. validate file encoding, character representation, and numeric character references; 2. validate if it is qualified for a well-formed XML document; 3. validate the specifications with our own purposes.

      「數位典藏與數位學習國家型科技計畫」提供一個藏品聯合搜尋的平台:「聯合目錄」。各機構計畫將藏品數位化後，提供藏品的metadata給聯合目錄，讓使用者只要透過聯合目錄便可搜尋到全國各機構計畫產出的數位化文化資產。聯合目錄對收納的藏品 metadata制定了統一格式，它的根標籤名稱為DACatalog，為了方便區別，我們稱這個metadata為「 DACatalog XML」。
      各典藏機構產出的metadata要匯入到聯合目錄之前，為了確保其格式符合DACatalog XML的規範，我們因此開發了一個metadata驗證工具「Digital Archive XML Validator」，任何藏品metadata都會經過此驗證工具，確保格式正確後，才能在聯合目錄上展出。
      DACatalog XML是建立在XML的基礎之上，除了必須符合XML文件的基本規則之外，同時也必須遵守聯合目錄額外制定的規範條件。下方列述的檢查規則，部分是依據經驗而制定，另一部分則是依據XML格式本身的規則限制。原則上檢查是按照下列規則出現的先後順序進行，當錯誤出現時，該檔案的檢查即會停止於最近的檢查階段，不會再繼續向下檢查。因此一個檔案若要走完全程的檢查關卡，檔案很可能必須經過檢查-修正-檢查-修正-檢查‥‥，多次循環，一直到零錯誤為止。

DACatalog XML 檢查規則:

一、檢查檔案編碼

  1. 檔案編碼限制為Big5：檢查檔案是否正確編碼的方式，是將檔案以其宣稱的編碼，將檔案解碼為文字後，再由人來判斷是否為可讀的文字，若是可讀的文字而非亂碼，則可判斷該檔案的確採用其所宣稱的編碼方式。但是我們想排除由人為檢查的方式，盡量找尋一些可用的法則來自動化處理檔案編碼的檢查，即使這個方法仍然有例外的情況發生。現階段我們採用的檢查方式，分成兩個步驟: 第一步先檢查檔案是否為unicode編碼，可藉由檢查byte order mark (BOM是位於檔案一開始的標示，可藉以判斷隨後的字串是採用何種unicode編碼)即可知道檔案是否採用了unicode編碼，因為現在已經有相當多的檔案採用了unicode的編碼方式，意即我們檢查的檔案出現unicode編碼的機率相當大，所以當檔案出現BOM的標示時，此檔案可隨即歸納為非Big5編碼的檔案，則完成檔案編碼的檢查。假使檔案非unicode編碼，則進入第二步驟的檢查方式，由於程式撰寫語言是採用JAVA，JAVA將檔案讀取轉為內部的字串型態(String)時，JAVA會把無法在編碼表裡對應轉換的字元以字元碼U+FFFD代替。因此第二步驟會掃描計算整個檔案轉換到JAVA的字串型態後出現的U+FFFD數目(轉換採用的編碼表為Big5)，我們設定當U+FFFD的總數超過15時，則假設此檔案非採用Big5編碼。
  2. Encoding屬性限制為Big5：由於限定處理的檔案編碼為Big5，所以在XML檔案一開始的第一行，即XML檔案進行版本及使用編碼宣告處，如<?xml version="1.0" encoding="Big5"?>，Encoding屬性必須為Big5。
  3. 是否有亂碼：依據我們過去經手處理過的XML檔案，各個機構單位將資料從資料庫轉出成XML時，由於編碼的問題未妥善處理，經常在我方接收的檔案裡會出現亂碼，這種編碼問題並非是採用非指定的編碼方式，而是經過錯誤轉換後的字元用Big5編碼儲存了起來。通常這樣的錯誤，也是要通過人去判讀檔案才會知道，但是我們發現某些符號會伴隨著亂碼大量出現，像是字元￿U+FFFF(空白)、U+003F(?)、U+25A1(□) ，因此我們設定當這三個字元在檔案中出現的總數超過15時，則認定此檔案很可能內含有大量的亂碼。雖然這個方法容易有例外的情形發生，但這個方法已經可以幫助過濾目前所知的亂碼檔案。
  4. 字元參引(NCR 或 Entity Reference)是否符合格式：字元參引會使用在兩個時機，使用時機之一是當字元無法用Big5編碼時，譬如使用外來語，像是日文或韓文，此時則必須用數字字元參引(NCR=Numeric Character Reference)來表示該字元。數字字元參引有兩種表示格式: &#dddd; 或 &#xhhhh;，其中dddd是字元在unicode的10進位值，而hhhh則是字元在unicode的16進行值，所以dddd及hhhh 此兩者的值是相等的。以一個字為例:「秘」在unicode的10進位值為31192，16進位值為79D8，所以「秘」的數字字元參引可表示為&#31192;或&#x79D8;。第二個使用字元參引的時機是碰到XML的5個特殊字元時，包括< > ' & "，必須分別用&lt; &gt; &apos; &amp; &quot;代替。字元參引會出現格式上的錯誤是源於這個字元「&」，「&」是字元參引表示法的字首，又是XML的其中一個特殊字元，所以有些粗心的資料處理人員，會將正確的字元參引經過替換XML特殊字元後而變成錯誤者，如&#25105;轉變成&amp;#25105;。所以凡是檔案中的字元參引格式不符合&#dddd;或 &#xhhhh;或&lt; &gt; &apos; &amp; &quot;者，則假設檔案可能有此項錯誤存在。
  5. 字元參引是否合理使用：因為每個中文字皆有可表示的字元參引，在疏忽的情況下偶會出現整個檔案的文字都用字元參引表示，為了能夠檢測出這樣的檔案，防止連一般的中文字都用字元參引表示，檔案內出現的字元參引都必須經由比對一份字元編碼表(中文字UTF-8,Big5碼對照表)，以確定檔案內的字元參引的確是表示Big5缺漏的文字。我們設定當不合理的字元參引出現超過10次，則假設檔案可能有此項錯誤存在。

二、XML文件需符合良好格式

  1. XML文件必須有一個根節點。以DACatalog XML為例，其根節點為DACatalog。
  2. 每個起始標籤必須對一個結束標籤，且標籤結構須為巢狀，不可交錯穿插。
  3. 同一個標籤內，屬性名稱不可重複。譬如<Title field="xxxx" field="xdddx">，只能有一個field。
  4. 屬性值必須包在雙引號(" ")內，且標籤命名須符合規則。標籤命名規則如下：
    • 標籤名稱用字可為英文字母、阿拉伯數字等文字。
    • 標籤名稱開頭不能是阿拉伯數字或是標點符號，也不能以xml (XML或Xml)這三個字作開頭。
    • 標籤名稱不能含有空白字元(space)。
  5. XML特殊字元必須用字元參引(Entity Reference)取代。
    特殊字元及代替的字元參引包括 <(&lt;) >(&gt;) &(&amp;) '(&apos;) "(&quot;)。
  6. 屬性值名稱僅允許field、dwc兩種屬性名稱
  7. 標籤的內容如果含有HTML標籤提出警告

三、檢查DACatalog XML的標籤結構及內容

  1. 檢查標籤名稱、階層、限定數目，標示於下方結構圖， =1表示該標籤只能有一個。DublinCore 15 項標籤包括Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, Rights。

  2. 檢查標籤內容值，各標籤(以XPath表示)內容的檢查細節詳述如下：
    • /DACatalog/AdminDesc/Project (value不可為空值)
      • /DACatalog/AdminDesc/Project[@Creator] (value不可為空值)
      • /DACatalog/AdminDesc/Project[@GenDate] (value不可為空值)
        • 時間可接受格式如下:
          "yyyy-MM-dd hh:mm:ss.S"
          "yyyy/MM/dd hh:mm:ss.S"
          "yyyy/MM/dd hh:mm:ss"
          "yyyy-MM-dd hh:mm:ss"
          "yyyy/MM/dd"
          "yyyy-MM-dd"
        • 時間可接受範圍: 不限 < GenDate < 現在
    • /DACatalog/AdminDesc/Catalog/Record
      • 至少要有「內容主題」與「典藏機構與計畫」兩種分類。
      • 分類間須以半形冒號(:)非全形冒號(：)作為區隔符號，並且須避免出現空分類的情況，如「內容主題:人類學::::雅美(Yami):器物」。
      • 以「內容主題」或「典藏機構與計畫」為分類開頭者，分類階層數不能小於3層。
      • 分類名稱不接受?(半形/全形), null, N/A, U+FFFD, 也不容許僅有一個英文字(N, A, n, a)。
      • 分類間應避免意義重覆，如「典藏機構與計畫:機構計畫: ‥‥」。
      • 「內容主題」分類的第2層，必須使用指定的分類詞彙，如:地質、新聞、生物、檔案…等。
    • /DACatalog/AdminDesc/DigiArchiveID (value不可為空值)
    • /DACatalog/AdminDesc/Hyperlink (value不可為空值)
      • 檢查連結的response code是否等於200(ok，表示連結成功)。
    • /DACatalog/AdminDesc/ICON (value不可為空值)
      • 檢查連結的response code是否等於200(ok，表示連結成功)。
      • 檢查連結的content type，此標籤的填充內容為網頁圖片連結，一般常見的網頁影像content type有image/gif, image/jpeg, image/png，為了確定此連結的標的物確實為影像，所以加入此檢查項。
    • /DACatalog/AdminDesc/Multimedia
      • 檢查連結的response code是否等於200(ok，表示連結成功)。

  3. 識別碼(DigiArchiveID)不能重複：DACatalog XML實際上是藏品的Metadata，而DigiArchiveID就是藏品的識別碼/辨識碼，所以每項藏品的DigiArchiveID都必須是獨一無二的，不可與他項藏品共用。檢查的前提是該次檢查的全部XML文件須先通過前面一、二兩項的檢測(即編碼檢測和XML文件符合良好格式)，並且全部XML文件的/DACatalog/AdminDesc/DigiArchiveID 皆存在並且非空值，才能檢測識別碼是否重覆。