從一個上古屬性urn說起
上一次，偶寫了一個對於
Cite元素的proposol（一個有趣的事情是該文沒有任何討論，但是被“踩”了3下，我其實很想知道踩我的人是基於什麽標準），在提議的末尾建議了一個標明所引用資源的URI的屬性。屬性名的選擇之一是“urn”。
今日偶爾上MSDN看reference，忽然看到叫做urn的屬性，點開一看，除了我已知的IE特有的namespace import中會有urn屬性，我們 爛熟於心的A標籤居然也有一個屬性叫urn，然而解釋卻語焉不詳：Sets or gets a URN for a target document. （這種註釋，寫了跟沒寫差不多……）
這個屬性有啥作用呢？似乎一點作用也無。google了半天，才終於找到線索。原來 HTML2.0的A元素有這個屬性！其用途是：
specifies a preferred, more persistent identifier for the head anchor of the hyperlink. The syntax and semantics of the URN attribute are not yet specified.
從這個設計意圖來看，此屬性顯然太過學究（甚至連語法和語義也沒有確定），殊無實踐價值，故在之後的HTML+和HTML3.0中都被去掉了。不意IE居然還殘留著這個上古遺物。我猜測這至少是從IE3傳承下來的，搞不好是從IE1甚至其前身Spyglass Mosaic那裡繼承來的——有心人自可考據一番。
不過反過來說，這個A上的urn屬性，其實反映了互聯網社群對於URI的早期看法（ MSDN對其的解釋也仍沿襲舊說），即URI分兩種，一種是URL，指示了資源的位置，一種是URN，指示了資源的命名（與尋址無關）。比如可以認為“http:”是URL scheme，而“isbn:”（應該【1】）是URN scheme。所以才會在一個A元素上，既有href屬性，也有urn屬性（所以HTML2對urn的解釋是“更永久化的標識”）。
【注1：實際現在的標準里並不存在“isbn:”scheme。】
但是後來，這個觀念轉變了。一種scheme沒有必要被硬性歸入URL或URN（抑或URC）。故“http:”是URI scheme，“urn:”也是URI scheme。後者定義了子空間，如“urn:isbn:n-nn-nnnnnn-n”中的isbn便是（“isbn”可稱為URN namespace ID，簡稱“URN NID”）。所以今天不再有URN schemes（注意這個s），而只有唯一一種“urn:”scheme，及其下的許多種URN NIDs。
NID可以自行創製（只要符合語法，並且不與已經通用的NID衝突），但若是要在公共領域廣泛使用，最好在IANA組織註冊，向世界宣佈這個NID已經為你所有了！ 這裡是所有已經註冊的NID。
回過頭來講，既然URI本身是通用統一的標識機制，使用現有的URI scheme也無差（譬如最常用的“http:”），自行創製一種特別的URN NID，除了顯擺，似乎也意義不大。這大概也是真正註冊的NID並不多的原因。
如，標識我昨天吃的盒飯（假設記帳需要），用 http://hax.iteye.com/eating/2010-10-28/bentou 也可以了（記住這只是個標識，不需要在javaeye的服務器上真實存在這樣一個文件），沒有必要搞一個 urn:hax:eating:20101028:bentou （我知道這樣顯得比較cool）。
如果你沒有自己的域名（因而無法確保唯一分配 http://mydomain/xxx 作為一個資源的標誌符），一個可選的方案是採用 “tag”scheme，比如：
tag:[email protected],1999:eating/2010-10-28/bentou
当年有人（据说是留学MIT的学生）在美國註冊了一些edu域名提供免費email服務，fudan.edu（注意沒有.cn）也是其中之一。后來這一批edu域名都被收回，今天你甚至在DNS上都查不到存在這個域名。但是我可以用“tag:[email protected],1999”来构造tag URI，因為偶是1999年时[email protected]這個信箱的擁有者。
除了mailbox，也可以用domain。比起 http://hax.iteye.com/eating/2010-10-28/bentou ，更好的方式或許是：
tag:hax.iteye.com,2007:eating/2010-10-28/bentou
因為我不能確保若干年後我還是hax.iteye.com的使用者。可能我會離開javaeye，或者javaeye倒閉了（或者CSDN倒閉了？）……世事难料，就此打住。
本文參考： http://www.w3.org/TR/uri-clarification/
今日偶爾上MSDN看reference，忽然看到叫做urn的屬性，點開一看，除了我已知的IE特有的namespace import中會有urn屬性，我們 爛熟於心的A標籤居然也有一個屬性叫urn，然而解釋卻語焉不詳：Sets or gets a URN for a target document. （這種註釋，寫了跟沒寫差不多……）
這個屬性有啥作用呢？似乎一點作用也無。google了半天，才終於找到線索。原來 HTML2.0的A元素有這個屬性！其用途是：
specifies a preferred, more persistent identifier for the head anchor of the hyperlink. The syntax and semantics of the URN attribute are not yet specified.
從這個設計意圖來看，此屬性顯然太過學究（甚至連語法和語義也沒有確定），殊無實踐價值，故在之後的HTML+和HTML3.0中都被去掉了。不意IE居然還殘留著這個上古遺物。我猜測這至少是從IE3傳承下來的，搞不好是從IE1甚至其前身Spyglass Mosaic那裡繼承來的——有心人自可考據一番。
不過反過來說，這個A上的urn屬性，其實反映了互聯網社群對於URI的早期看法（ MSDN對其的解釋也仍沿襲舊說），即URI分兩種，一種是URL，指示了資源的位置，一種是URN，指示了資源的命名（與尋址無關）。比如可以認為“http:”是URL scheme，而“isbn:”（應該【1】）是URN scheme。所以才會在一個A元素上，既有href屬性，也有urn屬性（所以HTML2對urn的解釋是“更永久化的標識”）。
【注1：實際現在的標準里並不存在“isbn:”scheme。】
但是後來，這個觀念轉變了。一種scheme沒有必要被硬性歸入URL或URN（抑或URC）。故“http:”是URI scheme，“urn:”也是URI scheme。後者定義了子空間，如“urn:isbn:n-nn-nnnnnn-n”中的isbn便是（“isbn”可稱為URN namespace ID，簡稱“URN NID”）。所以今天不再有URN schemes（注意這個s），而只有唯一一種“urn:”scheme，及其下的許多種URN NIDs。
NID可以自行創製（只要符合語法，並且不與已經通用的NID衝突），但若是要在公共領域廣泛使用，最好在IANA組織註冊，向世界宣佈這個NID已經為你所有了！ 這裡是所有已經註冊的NID。
回過頭來講，既然URI本身是通用統一的標識機制，使用現有的URI scheme也無差（譬如最常用的“http:”），自行創製一種特別的URN NID，除了顯擺，似乎也意義不大。這大概也是真正註冊的NID並不多的原因。
如，標識我昨天吃的盒飯（假設記帳需要），用 http://hax.iteye.com/eating/2010-10-28/bentou 也可以了（記住這只是個標識，不需要在javaeye的服務器上真實存在這樣一個文件），沒有必要搞一個 urn:hax:eating:20101028:bentou （我知道這樣顯得比較cool）。
如果你沒有自己的域名（因而無法確保唯一分配 http://mydomain/xxx 作為一個資源的標誌符），一個可選的方案是採用 “tag”scheme，比如：
tag:[email protected],1999:eating/2010-10-28/bentou
当年有人（据说是留学MIT的学生）在美國註冊了一些edu域名提供免費email服務，fudan.edu（注意沒有.cn）也是其中之一。后來這一批edu域名都被收回，今天你甚至在DNS上都查不到存在這個域名。但是我可以用“tag:[email protected],1999”来构造tag URI，因為偶是1999年时[email protected]這個信箱的擁有者。
除了mailbox，也可以用domain。比起 http://hax.iteye.com/eating/2010-10-28/bentou ，更好的方式或許是：
tag:hax.iteye.com,2007:eating/2010-10-28/bentou
因為我不能確保若干年後我還是hax.iteye.com的使用者。可能我會離開javaeye，或者javaeye倒閉了（或者CSDN倒閉了？）……世事难料，就此打住。
本文參考： http://www.w3.org/TR/uri-clarification/