是什么造就了一个很酷的URI？酷URI是不变的URI。什么样的URI会发生变化？URI不会改变：人们会改变它们。
人们在理论上根本没有理由更改URI(或停止维护文档)，但在实践中却有数百万个理由。
理论上，域名空间所有者拥有域名空间，因此拥有其中的所有URI。除资不抵债外，没有什么能阻止域名所有者保留该名称。从理论上讲，域名下的URI空间完全在您的控制之下，所以您可以随心所欲地使其稳定。文档从Web上消失的唯一好理由很可能是，拥有域名的公司破产了，或者再也负担不起保持服务器运行的费用了。那为什么世界上有这么多悬挂链接呢？部分原因是缺乏深谋远虑。以下是你在外面听到的随身听的季节：
您真的觉得旧的URI不能继续运行吗？如果是这样的话，你选错了他们。想想你的新车，这样你就能在下一次重新设计后继续运行。
我们有如此多的材料，以至于我们无法记录哪些是过时的，哪些是机密的，哪些是有效的，所以我们认为最好把所有的东西都关掉。
我对此深表同情--W3C经历了一段类似的时期，在将档案公之于众之前，我们必须仔细筛选保密的档案材料。解决方案是经过深思熟虑的--确保在每个文档中记录其可接受的分发版本、创建日期以及理想的到期日期。保留此元数据。
这是最站不住脚的借口之一。很多人不知道，像Apache这样的服务器让您可以很好地控制对象的URI和表示对象的文件在文件系统中的实际位置之间的灵活关系。可以将URI空间看作是一个组织良好的抽象空间。然后，将其映射到您实际用来实现它的任何现实上。然后，告诉您的服务器。您甚至可以编写服务器的几个部分来使其恰到好处。
那个URI在做什么，上面有约翰的名字？在他的目录里吗？我明白了。
为此，我们过去使用CGI脚本，现在使用二进制程序。
有一种疯狂的想法，认为脚本生成的页面必须位于cgibin或cgi区域。这暴露了您如何运行服务器的机制。您更改了机制(甚至保持内容不变)，然后哎呀-您的所有URI都改变了。
开始寻找文件的主页显然不会在几年后出现在那里值得信赖的东西。"；cgi-bin"；和"；old浏览"；和"；.pl"；都指向一些“我们现在如何做”的内容。相比之下，如果您使用页面来查找文档，您首先会得到一个同样糟糕的结果。
对于文档的索引页，但相比之下，html文档本身要好得多：
看一下这个，pubs/1998；标头将为任何未来的归档服务提供一个很好的线索，表明旧的1998年的文档分类方案正在进行中。虽然到了2098年，文档编号可能会有所不同，但我可以想象这个URI仍然有效，NSF或任何存档机构都不会对此感到难堪。
这可能是有关骨灰盒讨论的最糟糕的副作用之一。一些人似乎认为，因为有关于名称空间的研究，这些名称空间将更加持久，他们可以像他们喜欢的那样对悬挂链接松懈，因为骨灰盒可以解决所有这些问题。如果你是这些人中的一员，那么请允许我破灭你的幻想。
我见过的大多数骨灰盒方案看起来都有点像权威ID，后面跟着您选择的日期和字符串，或者只是您选择的字符串。这看起来非常像HTTP URI。换句话说，如果您认为您的组织将能够创建持久的URN，那么现在就这样做并将它们用于您的HTTP URI来证明这一点。HTTP没有任何让您的URI不稳定的地方。这是你的组织。创建一个数据库，将文档URN映射到当前文件名，并让Web服务器使用它来实际检索文件。
如果你已经做到了这一点，那么除非你有时间、金钱和人脉来完成一些软件设计，否则你可以说是下一个借口：
现在有一个我可以同情的。我完全同意。您需要做的是让Web服务器立即查找持久URI并返回该文件，无论您当前疯狂的文件系统将其存储在何处。您希望能够将URI作为acheck存储在文件中，并始终使数据库与实际情况保持一致。您希望存储同一文档的不同版本和翻译之间的关系，并且希望保持校验和的独立记录，以防止意外错误导致文件损坏。而网络服务器并不具备这些开箱即用的功能。当您想要创建新文档时，编辑器会要求您提供URI，而不是告诉您。
您需要能够在不更改URI的情况下更改URI空间中文档的所有权、访问权限、归档级别、安全级别等内容。
太可惜了。但是我们会到那里的。在W3C，我们使用Jigedit功能(用于编辑的Jigsaw服务器)来跟踪版本，并且我们正在试验文档创建脚本。如果你制作工具、服务器和客户端，请注意！
这是一个突出的原因，例如，它适用于许多W3C页面，包括这个页面：所以按我说的做，而不是按我做的做。
当您更改服务器上的URI时，您永远无法完全知道谁会链接到旧的URI。他们可能从常规网页上制作了链接。他们可能已经给你的页面加了书签。他们可能在写给朋友的信的页边空白处草草写上了URI。
当有人关注链接而链接断开时，他们通常会对服务器的所有者失去信心。他们也会因为实现目标而感到沮丧--无论是在情感上还是在实践上。
有足够多的人一直在抱怨悬挂链接，我希望损害是显而易见的。我希望这一点也很明显，声誉损害是对文档丢失的服务器的维护者造成的。
分配URI是网站管理员的职责，您可以在2年后、20年后、200年后随时待命。这需要思考，需要组织，需要承诺。
当URI中包含一些更改的信息时，URI就会更改。你如何设计它们是至关重要的。(什么，设计一个URI？我必须设计URI吗？是的，您必须考虑一下。)。设计主要意味着省略信息。
文档的创建日期-发布URI的日期-是不会更改的。它对于区分使用新系统的请求和使用旧系统的请求非常有用。这是开始一个URI很好的一件事。如果文档以任何方式标注了日期，即使它将是几代人都感兴趣的，那么这个日期就是一个很好的开始。
唯一的例外是故意将页面设置为最新的页面，例如，整个组织或其中的很大一部分都是最新的页面。
是“Money”杂志上最新的“Money Daily”专栏。这个URI中不需要日期的主要原因是，URI的持久性没有理由超过杂志。如果货币退出生产，那么今天货币的概念就消失了。如果您想要链接到内容，您可以链接到它在归档中单独出现的位置。
(看起来不错。假设金钱在pathfinder.com的整个生命周期中都意味着同样的事情。有一个重复的"；98&34；和一个"；.html&34；您不需要，但除此之外，它看起来像一个强URI)。
所有的一切！在创建日期之后，在名称中添加任何信息都是在以这样或那样的方式自找麻烦。
作者名称-作者身份可能会随着新版本的变化而改变。人们退出组织，把事情传下去。
实验对象。这很棘手。它在当时看起来总是很好，但变化之快令人惊讶。下面我将对此进行更多讨论。
诸如"；旧&34；和"；草稿等状态目录，更不用说"；最新&34；和"；COOL"；这样的目录遍布文件系统。单据更改状态-否则生成草稿就没有意义了。无论文档的状态如何，文档的最新版本都需要持久标识符。把身份从名字里去掉。
进入。在W3C，我们将网站分为团队访问、成员访问和公共访问。这听起来不错，但文档当然是从团队想法开始，与成员讨论，然后公开。如果每次打开某个文档进行更广泛的讨论时，所有指向它的旧链接都失败，那确实是一种遗憾！我们现在切换到一个简单的日期代码。
文件扩展名。这是很常见的一种。"；cgi"；，甚至"；.html"；都会发生变化。您可能在20年内不会对该页面使用HTML，但您可能希望今天指向该页面的链接仍然有效。建立到W3C站点的链接的规范方式不使用扩展名。(如何使用？)。
软件机制。查看"；cgi&34；、"；exec&34；和其他赠品&34；查看我们在URI中使用的是什么软件。有人想终身使用Perl CGI脚本吗？不是吗？去掉.pl。阅读服务器手册了解如何执行此操作。
我将更详细地讨论这一危险，因为它是最难避免的事情之一。通常，当您根据所做工作的细目对文档进行分类时，主题最终会出现在URI中。这种故障将会改变。区域的名称将会更改。在W3C，我们希望将标记更改为标记，然后更改为HTML，以反映该部分的实际内容。另外，请注意这通常是平面名称空间。100年后，你确定你不会再使用任何东西吗？例如，在我们短暂的生命中，我们想要重复使用历史和样式表。
这是一种组织网站的诱人方式，实际上也是一种组织任何东西(包括整个网络)的诱人方式。这是一个很好的中期解决方案，但从长远来看有严重的缺点。
造成这种情况的部分原因在于意义哲学。每一分钟，它都是一个潜在的群集主题，每个人对它的意思都可能有不同的想法。因为主题之间的关系是网络状的，而不是树状的，即使对于那些同意使用不同的树表示的人来说也是如此。这些是我(经常重复)对等级分类作为一般解决方案的危险的一般性评论。
实际上，当您在URI中使用主题名称时，您将自己绑定到某个分类。你将来可能会更喜欢不同的一种。那么，URI就很容易中断。
使用主题区域作为URI的一部分的一个原因是，URI空间的子部分的责任通常是委派的，然后您需要对该子空间负责的组织机构(子部门或组或其他什么)的名称。这将把您的URI绑定到组织结构。通常只有在更靠上的URI(位于其左侧)的日期保护下才是安全的：1998/PICES可以理解为您的服务器指的是我们在1998年所说的PICS，而不是我们在1998年对我们现在所说的PICS所做的那样。
请记住，这不仅适用于URI的路径部分，也适用于服务器名称。如果您的一些内容有单独的服务器，请记住，如果不破坏许多链接，这种划分是不可能改变的。一些经典的软件看看我们今天使用的域名是什么，cgi.pathfinder.com"；，"；Secure"；，"；lists.w3.org"；。它们是为了使服务器的管理变得更容易。无论它代表您公司的部门、文档状态、访问级别或安全级别，在将多个域名用于多个类型的文档之前都要非常非常小心。请记住，您可以使用重定向和代理将多个Web服务器隐藏在一个明显的Web服务器中。
哦，一定要考虑一下你的域名。如果您的名字不是SOAP，即使您已将产品线切换到其他产品线，您也会希望别人称您为Soap.com&34；吗？(向当时拥有soap.com的人道歉)。
保留URI，使它们在2年、20年、200年甚至2000年后仍然存在，显然不像听起来那么简单。然而，在整个网络上，网站管理员都在做出决定，这将使他们自己在未来变得非常困难。通常，这是因为他们使用的工具被认为是在当前呈现最好的站点，而没有人评估当事情发生变化时，链接会发生什么变化。然而，这里要传达的信息是，很多很多事情都可以改变，您的URI可以并且应该保持不变。只有当你思考你是如何设计它们的时候，它们才能做到。
(回到针对服务器管理员的礼仪，回到您的工作结构)如果您使用的是Apache，那么您可以将其设置为进行内容协商。您在文件(例如mydog.png)上保留文件扩展名(如.png)，但引用没有该扩展名的Web资源。然后，Apache会检查目录中具有该名称和任何扩展名的所有文件，DIT还可以从一组文件(例如GIF和PNG)中挑选最好的文件。(您不必将不同类型的文件放在不同的目录中，事实上，如果您这样做，内容协商将不起作用。)。
带有扩展名的引用仍然有效，但不会让您的服务器从当前可用的和未来的格式中选择最好的格式。
(事实上，mydog、mydog.png和mydog.gif都是有效的Web资源。我的狗是Content-type-Generic。(mydog.png和mydog.gif是特定于内容类型的。)。
当然，如果您正在构建自己的服务器，那么使用数据库将持久标识符与其当前形式相关联是一个非常干净的想法--尽管要注意数据库的无限增长。
1999年期间，我在http://www.whdh.com/stormforce/closings.shtmlwas上找到了一个页面，记录了学校因下雪而关闭的情况。让他们滚动通过电视屏幕底部的另一种选择！我在我的主页上放了一个指针。2000年的第一场大风暴来临了，我看了看这一页。上面写着，
"；截止日期为。目前没有有效的关闭。请在天气允许的时候再来看看"；
不可能有这么大的风暴。有趣的是日期不见了。但是如果我打开这个网站的主页，就会看到一个关闭学校的大按钮，它把我带到了http://www.whdh.com/stormforce/，上面有许多关闭的学校的名单。
嗯，也许他们改变了从最终列表中获得结束语的系统--但是他们不需要改变URI。
与日俱增的对网络的依赖带来的一个聪明之处是，应用程序可以有内置的链接回到制造商的网站。这在很大程度上已经被使用和滥用了，但是-你必须保持URL不变。就在前几天，我尝试了一个来自Microsoft NetMeeting 2/Something客户端的链接，该链接位于菜单帮助/Microsoft on the Web/FreeStuff&34；下，收到错误404-未找到来自服务器的响应。他们现在可能已经修好了。
(C)1998年Tim BL历史笔记：在这篇文章写于20世纪末的时候，“酷”是一个赞许的称谓，尤其是在年轻的、表明潮流、品质或适当性的人中。在抢注我们的DNS领域中，域名和URI路径的选择有时更多地指向表面上的酷，而不是有用或长寿。这张纸条是试图重新引导追求酷背后的能量。