¿Qué URI es genial?
Uno que no cambia.
¿Cómo cambian las URI?
Los URI no cambian: la gente los cambia.
En teoría, no hay ninguna razón para que los humanos cambien las URI (o dejen de mantener documentos), pero en la práctica hay millones.
En teoría, el propietario nominal del espacio de nombres de dominio realmente es el propietario del espacio de nombres de dominio y, por lo tanto, de todos los URI que contiene. Aparte de la insolvencia, nada impide que el propietario del nombre de dominio conserve este nombre. Y, en teoría, el espacio URI bajo su nombre de dominio está completamente bajo su control, por lo que puede hacerlo tan estable como desee. Prácticamente, la única buena razón para que un documento desaparezca de Internet es que la empresa propietaria del nombre de dominio se ha ido a la quiebra o ya no puede permitirse mantener el servidor en funcionamiento. Entonces, ¿por qué hay tantos eslabones perdidos en el mundo? Esto es en parte solo una falta de previsión. Estas son algunas de las razones por las que puede escuchar:
Simplemente reorganizamos el sitio para mejorarlo.
¿De verdad sientes que las antiguas URI ya no funcionan? Si es así, los ha elegido muy mal. Considere mantener los nuevos para el próximo rediseño.
Tenemos tanto material que no podemos hacer un seguimiento de lo que está desactualizado, lo que es confidencial y lo que sigue siendo relevante, por lo que pensamos que era mejor simplemente apagarlo.
Solo puedo simpatizar. El W3C ha pasado por un período en el que tuvimos que examinar cuidadosamente el material de archivo en busca de confidencialidad antes de hacerlo público. La decisión debe pensarse con anticipación: asegúrese de registrar con cada documento un rango aceptable de lectores, la fecha de creación e, idealmente, la fecha de vencimiento. Guarde estos metadatos.
Bueno, descubrimos que necesitábamos mover archivos ...
Ésta es una de las excusas más patéticas. Mucha gente no sabe que los servidores web le permiten controlar la relación entre el URI de un objeto y su ubicación real en el sistema de archivos. Piense en un espacio URI como un espacio abstracto, perfectamente organizado. Luego, mapee a cualquier realidad que realmente use para implementarlo. Luego, infórmelo al servidor web. Incluso puede escribir un fragmento de su servidor para hacerlo bien.
John ya no mantiene este archivo, ahora Jane lo hace.
¿Estaba el nombre de John en la URI? No, ¿solo el archivo estaba en su directorio? Bueno esta bien.
Solíamos usar un script CGI para esto, pero ahora usamos un programa binario.
Existe la loca idea de que las páginas con guiones deben ubicarse en el área "cgibin" o "cgi". Esto expone el mecanismo de cómo inicia su servidor web. Cambie el mecanismo (incluso manteniendo el contenido) y ¡Ups! Todos sus URI cambian.
Tome la National Science Foundation (NSF) por ejemplo: NSF
Online Documents
http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl
La primera página para comenzar a ver documentos claramente no seguirá siendo la misma en unos años.
cgi-bin, oldbrowsey pl todo esto da partículas de información sobre cómo-lo-hacemos-ahora. Si usa la página para buscar un documento, primero obtiene un resultado igualmente malo:
Informe del grupo de trabajo sobre criptología y teoría de codificación
http://www.nsf.gov/cgi-bin/getpub?nsf9814
para la página de índice del documento, aunque el documento html en sí se ve mucho mejor:
http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm
Aquí, el encabezado pubs / 1998 dará a cualquier servicio de archivo futuro una buena pista de que el antiguo esquema de clasificación de documentos de 1998 está en vigor. Aunque los números de los documentos pueden verse diferentes en 2098, puedo imaginar que este URI seguirá siendo válido y no interferirá con la NSF ni con ninguna otra organización que mantenga el archivo de ninguna manera.
No pensé que se suponía que las URL fueran persistentes, eran URN.
Este es probablemente uno de los peores efectos secundarios de la discusión sobre URN. Algunas personas piensan que debido a la investigación en un espacio de nombres más persistente, pueden ser descuidados con los enlaces colgantes porque "los URN lo arreglarán todo". Si eres una de estas personas, déjame decepcionarme.
La mayoría de los esquemas URN que he visto parecen un identificador de autoridad seguido de la fecha y la cadena que seleccione o simplemente la cadena que seleccione. Esto es muy similar al HTTP URI. En otras palabras, si cree que su organización podrá crear URN de larga duración, demuéstrelo ahora utilizándolos para sus URI HTTP. No hay nada en HTTP en sí mismo que haga que su URI sea inestable. Solo tu organización. Cree una base de datos que asigne el URN del documento al nombre del archivo actual y deje que el servidor web lo use para recuperar los archivos.
Si ha llegado a este punto, entonces si no tiene el tiempo, el dinero y las conexiones para desarrollar algún tipo de software, entonces puede exponer la siguiente excusa:
Queríamos hacerlo, pero simplemente no tenemos las herramientas adecuadas.
Pero puedes simpatizar con esto. Estoy totalmente de acuerdo. Lo que debe hacer es forzar al servidor web a procesar instantáneamente el URI persistente y devolver el archivo donde sea que esté almacenado actualmente en su loco sistema de archivos actual. Desea mantener todos los URI en un archivo como verificación y mantener la base de datos actualizada en todo momento. Desea conservar la relación entre las diferentes versiones y traducciones del mismo documento, y también mantener un registro independiente de la suma de comprobación para protegerlo contra errores accidentales en el archivo. Y los servidores web simplemente no salen de la caja con estas características. Cuando desea crear un nuevo documento, su editor solicita un URI.
Necesita la capacidad de cambiar la propiedad, el acceso a los documentos, la seguridad a nivel de archivo, etc. en el espacio URI sin cambiar el URI.
Es muy malo. Pero arreglaremos la situación. En el W3C, usamos la funcionalidad Jigedit (un servidor de edición de Jigsaw) que realiza un seguimiento de las versiones y experimentamos con scripts de creación de documentos. Si está desarrollando herramientas, servidores y clientes, ¡preste atención a este problema!
Esta excusa se aplica también a muchas páginas del W3C, incluida esta: así que haz lo que digo, no lo que hago.
¿Por qué debería importarme?
Cuando cambia el URI en su servidor, nunca puede saber quién hará referencia al antiguo URI. Estos pueden ser enlaces de páginas web normales. Marcadores de su página. El URI puede haber sido rayado en el margen de una carta a un amigo.
Cuando alguien hace clic en un enlace y se rompe, normalmente pierde la confianza en el propietario del servidor. También está decepcionado, tanto emocional como realistamente por la incapacidad de lograr su objetivo.
Mucha gente se queja constantemente de enlaces rotos y espero que el daño sea obvio. Espero que el daño a la reputación del responsable del mantenimiento del servidor donde desapareció el documento también sea obvio.
¿Entonces qué debo hacer? Diseño URI
Es responsabilidad del webmaster asignar URI que se puedan usar en 2 años, en 20 años, en 200 años. Esto requiere consideración, organización y compromiso.
Los URI cambian si alguna información cambia en ellos. Cómo los diseñas es muy importante. (¿Qué, diseño de URI? ¿Necesito diseñar un URI? Sí, deberías pensarlo). Diseño básicamente significa no tener ninguna información en la URI.
La fecha en que se creó el documento, la fecha en que se emitió el URI, algo que nunca cambiará. Es muy útil para separar las solicitudes que usan el nuevo sistema de las que usan el antiguo. Es un buen punto de partida para una URI. Si el documento tiene fecha, incluso si el documento es relevante en el futuro, este es un buen comienzo.
La única excepción es una página que es intencionalmente la versión "más reciente", por ejemplo, para toda la organización o una gran parte de ella.
http://www.pathfinder.com/money/moneydaily/latest/
Esta es la última columna de la revista Money Daily in Money. La razón principal por la que este URI no necesita una fecha es porque no hay ninguna razón para almacenar un URI que sobrevivirá al registro. El concepto de Money Daily desaparecerá cuando Money desaparezca. Si desea vincular el contenido, debe vincularlo por separado en los archivos:
http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html
(Se ve bien. Se asume que "dinero" significará lo mismo durante la vida de pathfinder.com. Hay un "98" duplicado y un ".html" innecesario, pero por lo demás parece un URI fuerte.
Que dejar de lado
¡Todos! Aparte de la fecha de creación, poner cualquier información en un URI es de una forma u otra suplicar problemas.
- Nombre del autor . La culpa puede cambiar con las nuevas versiones. La gente deja las organizaciones y pasa cosas a otros.
- Asunto . Es muy difícil. Siempre se ve bien al principio, pero cambia sorprendentemente rápido. Hablaré más sobre esto a continuación.
- Estado . En todos los sistemas de archivos aparecen directorios como "antiguo", "borrador", etc., por no mencionar "más reciente" y "genial". Los documentos cambian de estado; de lo contrario, no tendría sentido crear borradores. La última versión de un documento necesita un identificador persistente, independientemente de su estado. Mantenga el estado fuera de nombre.
- . W3C , . , , , , , . , , , - , ! .
- . . "cgi", ".html" . , 20 HTML , . W3C ( ).
- Mecanismos de software . En el URI, busque "cgi", "exec" y otros términos que griten "mira qué software estamos usando". ¿Alguien quiere dedicar toda su vida a los scripts CGI de Perl? ¿No? Luego elimine la extensión .pl. Lea el manual del servidor sobre cómo hacer esto.
- Nombre del disco. ¡Venga! Pero lo he visto.
Entonces, el mejor ejemplo de nuestro sitio es simplemente
http://www.w3.org/1998/12/01/chairs
… Un informe de las actas de la reunión de los presidentes del W3C.
Temas y clasificación por tema
Voy a entrar en más detalles sobre este peligro, ya que es una de esas cosas que son más difíciles de evitar. Por lo general, los temas terminan en URI cuando clasifica sus documentos por trabajo en progreso. Pero este desglose cambiará con el tiempo. Los nombres de las áreas cambiarán. En el W3C, queríamos cambiar MarkUP a Markup y luego HTML para reflejar el contenido real de la sección. Además, el espacio de nombres suele ser plano. Después de 100 años, ¿estás seguro de que no querrás reutilizar nada? En nuestra corta vida, ya queríamos reutilizar "Historia" y "Hojas de estilo", por ejemplo.
Es una forma tentadora de organizar un sitio web y una forma realmente tentadora de organizar cualquier cosa, incluida toda la Web. Ésta es una excelente solución a medio plazo, pero tiene serios inconvenientes a largo plazo.
Parte de la razón radica en la filosofía del significado. Cada término del lenguaje es un posible objeto de agrupamiento, y cada persona puede tener una idea diferente de lo que significa. Dado que la relación entre los sujetos se parece más a una telaraña que a un árbol, incluso aquellos que estén de acuerdo con la telaraña pueden elegir una representación diferente del árbol. Estas son mis observaciones generales (a menudo repetidas) sobre los peligros de la clasificación jerárquica como solución general.
De hecho, cuando usa un nombre de tema en un URI, se está atando a algún tipo de clasificación. Puede elegir una opción diferente en el futuro. Entonces el URI estará sujeto a violación.
La razón para usar un área temática como parte de un URI es que la responsabilidad de las subsecciones de un espacio URI generalmente se delega, en cuyo caso necesita el nombre del cuerpo organizacional (una unidad, grupo o lo que sea) que es responsable de ese subespacio. Esta es la vinculación del URI a la estructura organizativa. Por lo general, solo es seguro cuando el URI más abajo (izquierda) está protegido por una fecha: 1998 / pics podría significar para su servidor "lo que queríamos decir en 1998 con imágenes" en lugar de "lo que hicimos con lo que ahora llamamos imágenes ".
No olvide su nombre de dominio
Recuerde que esto se aplica no solo a la ruta en el URI, sino también al nombre del servidor. Si tiene servidores separados para cosas diferentes, recuerde que esta separación no se puede cambiar sin destruir muchos, muchos enlaces. Algunos errores clásicos como "mira qué software estamos usando hoy" son los nombres de dominio "cgi.pathfinder.com", "seguro", "lists.w3.org". Están diseñados para facilitar la administración del servidor. Independientemente de si el dominio representa un departamento específico dentro de su empresa, el estado del documento, el nivel de acceso o el nivel de seguridad, tenga mucho, mucho cuidado antes de usar más de un nombre de dominio para varios tipos de documentos. Recuerde que puede ocultar muchos servidores web dentro de un servidor web visible,mediante redirección y proxy.
Sí, y también piense en su nombre de dominio. No querrás que te llamen soap.com después de cambiar tu línea de productos y dejar de fabricar jabón (lo siento por el dueño de soap.com en este momento).
Conclusión
Guardar un URI durante 2, 20, 200 o incluso 2000 años obviamente no es tan fácil como parece. Sin embargo, en Internet, los webmasters están tomando decisiones que realmente les dificultarán las cosas en el futuro. A menudo, esto se debe a que están usando herramientas cuyo trabajo es presentar el mejor sitio solo en este momento, y nadie ha estimado qué pasará con los enlaces cuando todo cambie. Sin embargo, el punto aquí es que muchas, muchas cosas pueden cambiar, y sus URI pueden y deben permanecer iguales. Esto solo es posible cuando piensa en cómo los crea.
Ver también:
Suplementos
Cómo eliminar extensiones de archivo ...
... desde un URI en el servidor web actual basado en archivos?
Si está utilizando Apache, por ejemplo, puede configurarlo para negociar contenido. Guarde la extensión del archivo (por ejemplo, .png) en un archivo (por ejemplo, mydog.png ), pero puede vincular a un recurso web sin ella. Apache luego verifica en el directorio todos los archivos con ese nombre y cualquier extensión, y puede elegir el mejor del conjunto (por ejemplo, GIF y PNG). Y no tiene que colocar diferentes tipos de archivos en diferentes directorios, de hecho, la negociación de contenido no funcionará si lo hace.
- Configure su servidor para negociar contenido
- Siempre haga referencia a URI sin extensión
Los enlaces de extensión seguirán funcionando, pero evitarán que su servidor elija el mejor formato disponible actualmente y en el futuro.
(De hecho,
mydog, mydog.pngy mydog.gif- códigos y recursos web mydog- un tipo de contenido universal de recursos, mydog.pngy mydog.gif- los recursos de un tipo particular de contenido).
Por supuesto, si está escribiendo su propio servidor web, entonces es una buena idea usar una base de datos para vincular las ID persistentes a su forma actual, aunque tenga cuidado con el crecimiento ilimitado de la base de datos.
Tablero de la vergüenza - Historia 1: Canal 7
Durante 1999, rastreé los cierres de escuelas debido a la nieve en una página
http://www.whdh.com/stormforce/closings.shtml. ¡No espere a que aparezca la información en la parte inferior de la pantalla del televisor! Lo he vinculado desde mi página de inicio. Llega la primera gran tormenta de nieve del 2000 y miro la página. Dice:
- A partir de.
Actualmente no hay nada cerrado. Regrese en caso de advertencias meteorológicas.
No puede ser la misma tormenta fuerte. Es curioso que falte la fecha. Pero si va a la página principal del sitio, habrá un gran botón "Escuelas cerradas", que lo llevará a una página
http://www.whdh.com/stormforce/con una larga lista de escuelas cerradas.
Quizás cambiaron el sistema para obtener la lista, pero no necesitaban cambiar el URI.
Tablero de la vergüenza - Historia 2: Microsoft Netmeeting
Con la creciente dependencia de Internet, surgió la idea inteligente de las aplicaciones en las que se pueden insertar enlaces al sitio web del fabricante. Esto se ha utilizado y abusado mucho, pero no puede cambiar la URL. El otro día probé un enlace del cliente Microsoft Netmeeting 2 / algo en el menú Ayuda / Microsoft en la Web / Cosas gratis y obtuve un error 404: no se encontró respuesta del servidor. Quizás ya esté arreglado ...
© 1998 Tim BL
Nota histórica: A finales del siglo XX, cuando se escribió esto, “cool” era un epíteto de aprobación, especialmente entre los jóvenes, que indica moda, calidad o idoneidad. Con prisa, la ruta URI a menudo se eligió por "cool" sobre la utilidad o la longevidad. Esta publicación es un intento de redirigir la energía detrás de la búsqueda de lo cool.
Ver también: