從一個上古屬性urn說起

上一次,偶寫了一個對於[url=http://hax.iteye.com/blog/759898]Cite元素的proposol[/url](一個有趣的事情是該文沒有任何討論,但是被“踩”了3下,我其實很想知道踩我的人是基於什麽標準),在提議的末尾建議了一個標明所引用資源的URI的屬性。屬性名的選擇之一是“urn”。

今日偶爾上MSDN看reference,忽然看到叫做urn的屬性,點開一看,除了我已知的IE特有的namespace import中會有urn屬性,我們[url=http://msdn.microsoft.com/en-us/library/ms535173.aspx]爛熟於心的A標籤[/url]居然也有一個屬性叫urn,然而解釋卻語焉不詳:Sets or gets a URN for a target document. (這種註釋,寫了跟沒寫差不多……)

這個屬性有啥作用呢?似乎一點作用也無。google了半天,才終於找到線索。原來[url=http://tools.ietf.org/html/rfc1866#page-33]HTML2.0的A元素[/url]有這個屬性!其用途是:

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的早期看法([url=http://msdn.microsoft.com/en-us/library/ms534710.aspx]MSDN對其的解釋[/url]也仍沿襲舊說),即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已經為你所有了![url=http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml]這裡是所有已經註冊的NID[/url]。

回過頭來講,既然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 作為一個資源的標誌符),一個可選的方案是採用[url=http://en.wikipedia.org/wiki/Tag_URI]“tag”scheme[/url],比如:
tag:hax@fudan.edu,1999:eating/2010-10-28/bentou

当年有人(据说是留学MIT的学生)在美國註冊了一些edu域名提供免費email服務,fudan.edu(注意沒有.cn)也是其中之一。后來這一批edu域名都被收回,今天你甚至在DNS上都查不到存在這個域名。但是我可以用“tag:hax@fudan.edu,1999”来构造tag URI,因為偶是1999年时hax@fudan.edu這個信箱的擁有者。

除了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倒閉了(或者优快云倒閉了?)……世事难料,就此打住。


本文參考:[url]http://www.w3.org/TR/uri-clarification/[/url]
采用PyQt5框架与Python编程语言构建图书信息管理平台 本项目基于Python编程环境,结合PyQt5图形界面开发库,设计实现了一套完整的图书信息管理解决方案。该系统主要面向图书馆、书店等机构的日常运营需求,通过模块化设计实现了图书信息的标准化管理流程。 系统架构采用典型的三层设计模式,包含数据存储层、业务逻辑层和用户界面层。数据持久化方案支持SQLite轻量级数据库与MySQL企业级数据库的双重配置选项,通过统一的数据库操作接口实现数据存取隔离。在数据建模方面,设计了包含图书基本信息、读者档案、借阅记录等核心数据实体,各实体间通过主外键约束建立关联关系。 核心功能模块包含六大子系统: 1. 图书编目管理:支持国际标准书号、中国图书馆分类法等专业元数据的规范化著录,提供批量导入与单条录入两种数据采集方式 2. 库存动态监控:实时追踪在架数量、借出状态、预约队列等流通指标,设置库存预警阈值自动提醒补货 3. 读者服务管理:建立完整的读者信用评价体系,记录借阅历史与违规行为,实施差异化借阅权限管理 4. 流通业务处理:涵盖借书登记、归还处理、续借申请、逾期计算等标准业务流程,支持射频识别技术设备集成 5. 统计报表生成:按日/月/年周期自动生成流通统计、热门图书排行、读者活跃度等多维度分析图表 6. 系统维护配置:提供用户权限分级管理、数据备份恢复、操作日志审计等管理功能 在技术实现层面,界面设计遵循Material Design设计规范,采用QSS样式表实现视觉定制化。通过信号槽机制实现前后端数据双向绑定,运用多线程处理技术保障界面响应流畅度。数据验证机制包含前端格式校验与后端业务规则双重保障,关键操作均设有二次确认流程。 该系统适用于中小型图书管理场景,通过可扩展的插件架构支持功能模块的灵活组合。开发过程中特别注重代码的可维护性,采用面向对象编程范式实现高内聚低耦合的组件设计,为后续功能迭代奠定技术基础。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值