¿Qué valores para el atributo rel de una etiqueta de enlace deberían usarse para representar una jerarquía de colecciones y documentos?

Question

Me gustaría representar enlaces a subcarpetas y documentos en una carpeta en documentos de hipertexto (posiblemente usando HAL). Por lo tanto, un documento que representa una carpeta debe tener enlaces a la carpeta principal, subcarpetas y archivos contenidos en la carpeta. Para la carpeta principal, < link rel = "up" href = ".. > parece ser la elección directa. Sin embargo, no estoy seguro de qué es lo más apropiado para los enlaces a subcarpetas y documentos contenidos en la carpeta. Hay un par de opciones definidas en RFC-5988. Sin embargo, no podría decir cuál sería más apropiado para representar un árbol de carpetas y archivos.

Podría crear mis propios valores y producir documentos. Por ejemplo (utilizando la sintaxis HTML en lugar de HAL de familiaridad):

... 
<link rel="self" href="http://example.com/some/folder/"> 
<link rel="up" href="http://example.com/some/"> 
<link rel="file" href="image1.jpg"> 
<link rel="file" href="image2.png"> 
<link rel="folder" href="subfolder/"> 
... 

Utilizar REL-atributos personalizados tiene la clara desventaja de las aplicaciones que consumen estos documentos que necesitan para tener un apoyo explícito a ellos. En consecuencia, prefiero usar algo que una aplicación pueda entender simplemente siguiendo los estándares y las mejores prácticas.

Actualización: AtomPub (RFC 5023)) parece utilizar rel = "editar" en los enlaces a los miembros de una colección. No tienen un concepto para subcolección, creo. rel = "subsection" de RFC-5988 podría ser una opción.

Answer 1

representar una jerarquía
Una forma muy común de representar una jerarquía es utilizar el concepto de relaciones padre-hijo entre los niveles de la jerarquía. Esto le permite describir la jerarquía muy generalmente sin vincularse a solo que representa carpetas y documentos ya que parent-child/children puede representar cualquier jerarquía. Los analizadores DOM, por ejemplo, usan este concepto en gran medida, ya que el DOM es una jerarquía.

Suponiendo que su jerarquía no está completamente equilibrada (es decir, puede tener documentos a 3 niveles de profundidad, y también a 20 niveles de profundidad), necesita saber en qué tipo de "nodo" se encuentra, una colección (carpeta) o una hoja (documento). Con la noción de colección vs. hoja, y de padre vs. hijo/hijos, podrá anotar fácilmente la relación de todos los enlaces que debería necesitar.

tipo de contenido
La parte más importante de cualquier interacción resto es la clara definición de los tipos de contenido, tanto en el cliente y el servidor. Los tipos de contenido son bastante oscuros en cuanto a lo que realmente necesitan, pero para sus propósitos podría ser tan poco como indicar que el "formato" de recursos generales es HAL y también definir el significado de los valores rel parent y child.

La mayoría de las personas se olvidan de que los tipos de contenido son para humanos. Solo los nombres de los tipos de contenido son importantes para los usuarios-agentes, no el contenido de la definición del tipo de contenido. Los desarrolladores (o very smart user agents) usan las definiciones de tipo de contenido para decidir cómo interpretar las cosas. El usuario-agente solo usa el nombre para cambiar los modos de interpretación.

Las normas no son todo
En general, es más importante que su aplicación para representar su propio recursos de la manera su aplicación necesidades a que para usted para tratar de meter con calzador su representación (s) en algunos "estándar". Si tiene sentido que su aplicación use up, folder y file, utilice todas las relaciones de enlace. La única advertencia es que tendría que pensar mucho acerca de cómo puede querer cambiar las cosas en el futuro. Cambiar una API no es lo más fácil de hacer, pero introducir un nuevo tipo de contenido y desaprobar uno más antiguo no es demasiado difícil.

No me malinterpreten, estoy a favor de los estándares, pero ellos, por su propia naturaleza, son casi siempre detrás del mundo real. Por ejemplo, el RCF no parece manejar bien las colecciones jerárquicas genéricas de las cosas.