Arquitectura de la World Wide Web, Volume One

Recomendacin W3C 15 de diciembre de 2004

Esta versin: http://www.w3.org/TR/2004/Rec-webarch-20041215/ ltima versin: http://www.w3.org/TR/webarch/ Versin anterior: http://www.w3.org/TR/2004/PR-webarch-20041105/ Editores: Ian Jacobs, W3C Norman Walsh, Sun Microsystems, Inc. Autores: Ver agradecimientos (8). Por favor consulte las erratas para este documento, que puede incluir algunas correcciones normativas. Vase tambin traducciones .
Copyright 2002-2004 W3C (MIT, ERCIM, Keio), todos los derechos reservados. Se aplican normas de W3C responsabilidad, marca registrada, uso de documento y licencias de software . Su interaccin con este sitio est en conformidad con nuestro pblico y declaraciones de privacidad de miembros .

Resumen
La World Wide Web utiliza tecnologas relativamente sencillas con suficiente escalabilidad, la eficiencia y la utilidad que ha traducido en un espacio de informacin extraordinaria de recursos interrelacionados, creciendo a travs de los medios de comunicacin, culturas y lenguas. En un esfuerzo para preservar estas propiedades del espacio de informacin a medida que las tecnologas evolucionan, este documento de arquitectura describe los componentes de diseo de la Web. Son la identificacin de recursos, la representacin del Estado del recurso y los protocolos que admiten la interaccin entre los agentes y recursos en el espacio. Nos relacionamos componentes de diseo, restricciones y buenas prcticas con los principios y propiedades que soportan.

Estado de este documento

Esta seccin describe el estado de este documento en el momento de su publicacin. Otros documentos pueden reemplazar este documento. Una lista de publicaciones actuales de W3C y la ltima revisin de este informe tcnico puede encontrarse en el ndice de informes tcnicos del W3C en http://www.w3.org/TR/. Este es el 15 de diciembre de 2004 la recomendacin de "Arquitectura de la World Wide Web, Volume One". Este documento ha sido revisado por los miembros del W3C, por los desarrolladores de software y por otros grupos de W3C y las partes interesadas y est avalada por el Director como una recomendacin del W3C. Es un documento estable y puede ser utilizado como material de referencia o citado desde otro documento. Papel del W3C en formular la recomendacin es para llamar la atencin a la especificacin y promover su implementacin generalizada. Esto mejora la funcionalidad e interoperabilidad de la Web. Este documento fue desarrollado por Grupo de arquitectura tcnica (TAG), la cual, por carta mantiene una lista de temas arquitectnicos W3C. El alcance de este documento es un subconjunto til de esas cuestiones; no se pretende abordar todas ellas. La etiqueta tiene la intencin de abordar las cuestiones restantes (y futuras) ahora que un volumen es publicado como una recomendacin del W3C. Un completo historial de cambios por lo que este documento est disponible. Enve sus comentarios sobre este documento a public-webarch-comments@w3.org (archivo pblico de pblico-webarch-comentarios). Anlisis tcnico de etiqueta tiene lugar en www-tag@w3.org (archivo pblico de www-tag). Este documento fue elaborado bajo la poltica de W3C DPI de julio de 2001 proceso documento. La etiqueta mantiene una lista pblica de divulgacin de patentes relacionadas con este documento; esa pgina tambin incluye instrucciones para revelar una patente. Una persona que tenga conocimiento real de una patente que el individuo cree que contiene Claim(s) esencial con respecto a esta especificacin debe revelar la informacin de conformidad con el artculo 6 de la Directiva de patentes de W3C.

Tabla de contenido
1. Introduccin 1.1. Acerca de este documento 1.1.1. Audiencia de este documento 1.1.2. El alcance de este documento 1.1.3. Principios, restricciones y buena prctica notas 2. La identificacin 2.1. Beneficios de URI

2.2. La URI de recursos relaciones 2.2.1. Colisin de URI 2.2.2. Asignacin de URI 2.2.3. Indirecta identificacin 2.3. URI comparaciones 2.3.1. Alias URI 2.3.2. Reutilizacin de representacin 2.4. Esquemas de URI 2.4.1. Registro de esquema URI 2.5. URI opacidad 2.6. El fragmento identificadores 2.7. Futuras direcciones para identificadores 2.7.1. Internacionalizados identificadores 2.7.2. Afirmacin que dos URIs identificar el mismo recurso 3. La interaccin 3.1. Mediante un URI para acceder a un recurso 3.1.1. Detalles de recuperar una representacin 3.2. La representacin tipos y tipos de medios de Internet 3.2.1. Representacin tipos y semntica de identificador de fragmento 3.2.2. Fragmento de identificadores y negociacin de contenido 3.3. Inconsistencias entre la datos de representacin y metadatos 3.4. Seguras interacciones 3.4.1. Rendicin de cuentas y las interacciones inseguras 3.5. Gestin de representacin 3.5.1. Persistencia de URI 3.5.2. Vinculacin y control de acceso 3.5.3. Apoyo de navegacin 3.6. Futuras direcciones para la interaccin 4. Formatos de datos 4.1. Binario y Textual de los formatos de datos 4.2. El control de versiones y extensibilidad 4.2.1. Control de versiones 4.2.2. Versioning y XML poltica de espacio de nombres 4.2.3. Extensibilidad 4.2.4. Composicin de formatos de datos 4.3. La separacin del contenido, la presentacin y la interaccin 4.4. Hipertexto 4.4.1. URI referencias 4.5. Formatos de datos basados en XML 4.5.1. Cundo se debe utilizar un formato basado en XML 4.5.2. Enlaces en XML 4.5.3. Espacios de nombres XML Punto 4.5.4. documentos Namespace 4.5.5. QNames en XML 4.5.6. Semntica de ID de XML 4.5.7. Soportes para XML 4.5.8. Fragmento de identificadores en XML 4.6. Futuras direcciones para datos de formatos 5. Arquitectura principios generales 5.1. Ortogonales especificaciones 5.2. Extensibilidad 5.3. Tratamiento de errores de 5.4. Basada en Protocolo de interoperabilidad 6. Glosario 7. Las referencias 7.1. Arquitectnicas especificaciones 8. Agradecimientos

Lista de principios, restricciones y buena prctica notas

Los siguientes principios, restricciones y notas de buenas prcticas son descritas en este documento y enumerados aqu para mayor comodidad. Tambin hay un Resumen de pie. Identificacin Identificadores globales (principio, 2) Identificar con URI 2.1 (prctica) URI identificar un nico recurso (restriccin, 2.2) URI evitando alias 2.3.1 (prctica) Uso de URI consistente 2.3.1 (prctica) Esquemas de URI reutilizar (prctica, 2.4) Opacidad URI (prctica, 2.5)

Interaccin Volver a utilizar formatos de representacin 3.2 (prctica) Incoherencia de metadatos de datos (restriccin, 3.3) Asociacin de metadatos 3.3 (prctica) Recuperacin segura (principio, 3.4) Representacin disponible (prctica, 3.5)

 Referencia no implica la eliminacin de referencias (principio, 3.5) Representacin consistente 3.5.1 (prctica) Formatos de datos Informacin sobre la versin 4.2.1 (prctica) Poltica de Namespace 4.2.2 (prctica) Mecanismos de extensibilidad 4.2.3 (prctica) Conformidad de extensibilidad 4.2.3 (prctica) Extensiones desconocidas 4.2.3 (prctica) Separacin del contenido, la presentacin, la interaccin 4.3 (prctica) Identificacin de enlace 4.4 (prctica) Enlace Web 4.4 (prctica) URI genrico 4.4 (prctica) Vnculos de hipertexto 4.4 (prctica) Adopcin de Namespace 4.5.3 (prctica) Documentos Namespace (prctica, punto 4.5.4) QNames indistinguibles de URI (restriccin, 4.5.5) Asignacin de QName 4.5.5 (prctica) XML y "texto / *" 4.5.7 (prctica) XML y codificaciones de caracteres 4.5.7 (prctica)

Principios de arquitectura general Ortogonalidad (principio, 5.1) Recuperacin de errores (principio, 5.3)

1. Introduccin
El World Wide Web (WWW, o simplemente Web) es un espacio de informacin en la que los elementos de inters, conocido como recursos, se identifican mediante identificadores globales llamados identificadores uniformes de recursos (URI ). Ejemplos como el siguiente escenario de viajes se utilizan a lo largo de este documento para ilustrar el comportamiento tpico de agentes Web personas o software actuando en este espacio de informacin. Un agente de usuario acta en nombre de un usuario. Agentes de software incluyen servidores, servidores proxy, araas, navegadores y reproductores multimedia.

Historia Al planear un viaje a Mxico, dice Nadia "informacin meteorolgica de Oaxaca: 'http://weather.example.com/oaxaca'" en una brillante revista de viajes. Nadia tiene suficiente experiencia en la Web para reconocer que "http://weather.example.com/oaxaca" es un URI y que es probable que sea capaz de recuperar informacin asociada con su navegador de Web. Cuando Nadia entra el URI en su navegador: 1. El navegador reconoce que ha escrito por Nadia es un URI. 2. El navegador realiza una accin de recuperacin de informacin de acuerdo con su comportamiento configurado para recursos identificados mediante el esquema URI "http". 3. La autoridad responsable de "weather.example.com" proporciona informacin en respuesta a la solicitud de recuperacin. 4. El navegador interpreta la respuesta, identificada como XHTML por el servidor y realiza acciones de recuperacin adicional para grficos integrados y otros contenidos segn sea necesario. 5. El navegador mostrar la informacin recuperada, que incluye vnculos de hipertexto a otra informacin. Nadia puede seguir estos enlaces hipertexto para recuperar informacin adicional. Este escenario ilustra las tres bases arquitectnicas de la Web que se describen en este documento: 1. Identificacin (2). URI se utilizan para identificar recursos. En este escenario de viajes, el recurso es un informe actualizado peridicamente sobre el clima en Oaxaca y el URI es "http://weather.example.com/oaxaca". 2. Interaccin (3). Agentes Web comunicarn utilizando protocolos estandarizados que permiten la interaccin a travs del intercambio de mensajes que se adhieren a un sintaxis definido y semntica. Entablar un dilogo de recuperacin un URI o seleccionando un vnculo de hipertexto, Nadia le dice a su navegador para realizar una accin de recuperacin del recurso identificado por el URI. En este ejemplo, el navegador enva una solicitud HTTP GET (parte del protocolo HTTP) en el servidor en "weather.example.com", a travs del puerto TCP/IP 80, y el servidor devuelve un mensaje que contiene lo que determina que una representacin del recurso en el momento que se gener la representacin. Tenga en cuenta que este ejemplo es especfica de hipertexto navegando de informacin otros tipos de interaccin son posibles, dentro de los exploradores y mediante el uso de otros tipos de agente Web; nuestro ejemplo sirve para ilustrar una interaccin comn, no definir el rango de posibles interacciones o limitar las maneras en que podran utilizar la Web de agentes. 3. Formatos (4). Hace la mayora de los protocolos utilizada para la recuperacin de la representacin o presentacin el uso de una secuencia de uno o varios mensajes, que en conjunto contienen una carga de datos de representacin y metadatos, para transferir la representacin entre los agentes. La eleccin del Protocolo de interaccin pone lmites sobre los formatos de datos de representacin y metadatos que pueden transmitirse. HTTP, por ejemplo, normalmente transmite una secuencia de octeto ms metadatos y utiliza el "Content-Type" e identifican los campos de la cabecera "Codificacin de contenido" para seguir el formato de la representacin. En este escenario, es la representacin transferida en XHTML, identificados por el campo de encabezado "Content-type" HTTP que contiene el tipo de medios

de comunicacin de Internet registrado, el nombre "aplicacin/xhtml + xml". Que los medios de Internet tipo nombre indica que se pueden procesar los datos de representacin de acuerdo con la especificacin XHTML. Navegador de Nadia est configurada y programado para interpretar la recepcin de una "aplicacin/xhtml + xml" representacin escrito como una instruccin para procesar el contenido de esa representacin de acuerdo con el modelo de representacin XHTML, incluyendo cualquier interaccin subsidiarios (como las peticiones de hojas de estilos externas o imgenes en lnea) solicitado por la representacin. En el escenario, los datos de representacin XHTML recibidos desde la solicitud inicial indica al explorador de Nadia tambin recuperar y procesar en lnea los mapas meteorolgicos, cada uno identificado mediante un URI y causando una accin de recuperacin adicional, resultando en representaciones adicionales que son procesadas por el explorador de acuerdo a sus propios formatos de datos (por ejemplo, "aplicacin/svg + xml" indica el formato de datos SVG), y este proceso contina hasta que todos los formatos de datos se han dictado. El resultado de todo este proceso, una vez que el navegador ha alcanzado un aplicacin estado estacionario que completa la accin solicitada inicial de Nadia, es comnmente como una "pgina Web". La ilustracin siguiente muestra la relacin entre el identificador de recurso y representacin.

En el resto de este documento, podemos destacar puntos arquitectnicos importantes acerca de los identificadores de Web, protocolos y formatos. Tambin analizaremos algunos importantes principios generales de la arquitectura (5) y cmo se aplican a la Web.

1.1. Acerca de este documento

Este documento describe las propiedades que deseamos de la Web y las opciones de diseo que se han hecho para alcanzarlos. Promueve la reutilizacin de las normas existentes cuando adecuado y proporciona orientacin sobre cmo innovar en consonancia con la arquitectura Web. Los trminos deben, no debe, deberia no debe y mayo se utilizan en los principios, las restricciones y notas de buenas prcticas de acuerdo con RFC 2119 [RFC2119]. Este documento no incluye disposiciones de conformidad por estas razones: Software conforme se espera que sea tan diversos que no sera til poder hacer referencia a la clase de agentes de software compatible. Algunas de las notas de buenas prcticas refieren a personas; Especificaciones generalmente definen conformidad para el software, no las personas. No creemos que la adicin de una seccin de conformidad es probable que aumente la utilidad del documento. 1.1.1. Audiencia de este documento Este documento pretende informar a discusiones sobre temas de arquitectura Web. El pblico objetivo de este documento incluye: 1. 2. 3. 4. Participantes en las actividades del W3C Otros grupos e individuos disear tecnologas para integrarse en la Web Entidades ejecutoras de las especificaciones de W3C Editores y autores de contenido web

Nota: Este documento no distingue en cualquier manera formal los trminos "idioma" y "formato". Contexto determina qu trmino se utiliza. La frase "diseador de especificacin" abarca el lenguaje, formato y diseadores de protocolo. 1.1.2. Alcance de este documento Este documento presenta la arquitectura general de la Web. Otros grupos dentro y fuera de W3C tambin abordan aspectos especializados de arquitectura Web, incluida la accesibilidad, calidad, internacionalizacin, independencia de dispositivos y servicios Web. La seccin de Especificaciones de la arquitectura (7.1) incluye referencias a estas especificaciones relacionadas. Este documento se esfuerza por un equilibrio entre la brevedad y precisin mientras incluyendo ejemplos ilustrativos. Resultados de etiqueta son documentos informativos que complementan el documento actual al proporcionar ms detalles sobre temas seleccionados. Este documento incluye algunos extractos de las conclusiones. Desde las conclusiones evolucionan de forma independiente, este documento incluye referencias a hallazgos de etiqueta aprobadas. Para otras cuestiones de etiqueta cubiertos por este documento, pero sin una conclusin aprobada, las referencias son las entradas de la lista de cuestiones de etiquetas. Muchos de los ejemplos de este documento que involucran actividad humana supongamos que el modelo de interaccin familiar de Web (ilustrado en el comienzo de la introduccin) donde un siguiente persona un vnculo a travs de un agente de usuario, el agente de usuario recupera y presenta los datos, el usuario sigue otro vnculo, etc.. Este documento no discutir en cualquier detalle otros modelos de interaccin, como voz navegando (vase, por ejemplo, [VOICEXML2]). La eleccin del modelo de interaccin puede tener un impacto en el comportamiento esperado. Por ejemplo, cuando un agente de grfica de usuario que se ejecuta en un ordenador porttil o dispositivo porttil encuentra un error, el agente de usuario puede informar de errores directamente al usuario a travs de seales de audio y vdeo y presentar al usuario con opciones para resolver los errores. Por otro lado, cuando alguien es navegar por la Web a travs de la voz de entrada y salida de slo audio, deteniendo el cuadro de dilogo para esperar a la entrada del usuario puede reducir usabilidad ya que es tan fcil de "perder el lugar" cuando se navega con slo de salida de audio. Este documento no discutir cmo se aplican los principios, las limitaciones y las buenas prcticas identificadas aqu en todos los contextos de interaccin. 1.1.3. Principios, restricciones y buena prctica notas Los puntos importantes de este documento se clasifican como sigue: Principio Un principio arquitectnico es una norma fundamental que se aplica a un gran nmero de situaciones y variables. Principios arquitectnicos incluyen "separacin de preocupaciones", "interfaz genrica", "Sintaxis autodescriptiva", "semntica visible", "efecto de red" (Ley de Metcalfe) y la ley de Amdahl: "la velocidad de un sistema est limitada por su componente ms lento". Restriccin En el diseo de la Web, algunas opciones, como los nombres de los elementos p y li en HTML, la eleccin de los dos puntos (: caracteres en URI o bits de agrupacin en unidades de ocho bits (octetos), son algo arbitrarias; si paragraph haba sido elegido en lugar de p o asterisco (*) en lugar de dos puntos, el resultado a gran escala sera, probablemente, ha sido los mismos. Este documento se centra en las opciones de diseo ms fundamentales: las opciones de diseo que conducen a las limitaciones, es decir, las restricciones en el comportamiento o la interaccin dentro del sistema. Pueden imponerse restricciones de tcnica, poltica o otros motivos para lograr propiedades deseables en el sistema, como la accesibilidad, mbito global, la relativa facilidad de evolucin, la eficiencia y la extensibilidad dinmica. Buenas prcticas Buenas prcticas por los desarrolladores de software, contenido autores, administradores, usuarios y diseadores de especificacin: aumenta el valor de la Web.

2. Identificacin
A fin de comunicar internamente, una comunidad acepta (en una medida razonable) en un conjunto de trminos y sus significados. Uno de los objetivos de la Web, desde sus inicios, ha sido construir una comunidad global en el que ningn partido puede compartir informacin con cualquier otra parte. Para lograr este objetivo, la Web hace uso de un sistema nico de identificacin global: el identificador URI. URI son una piedra angular de la arquitectura Web, proporcionando la identificacin que es comn a travs de la Web. El alcance global de URI promueve a gran escala "efectos de red": el valor de un identificador aumenta cuanto ms se usa siempre (por ejemplo, cuanto ms se utiliza en vnculos de hipertexto (4.4)).

Principio: identificadores globales Nomenclatura global conduce a efectos de red global. Este principio se remonta por lo menos en cuanto a trabajo seminal de Douglas Engelbart en sistemas abiertos de hipertexto; Consulte la seccin Cada objeto direccionables en [Eng90].

2.1. Beneficios de URI

La eleccin de sintaxis para identificadores globales es algo arbitraria; es su mbito global que es importante. El Identificador uniforme de recursos, [URI], se ha implementado con xito desde la creacin de la Web. Hay beneficios sustanciales para participar en la red existente de URI, incluida la vinculacin, marcadores, cach e indexacin por los buscadores, y hay costos importantes para crear un nuevo sistema de identificacin que tiene las mismas propiedades que URIs.

Buenas prcticas: identificar con URIs

Para beneficiarse y aumentar el valor de la World Wide Web, agentes deberan proporcionar a URIs como identificadores de recursos. Un recurso debe tener un URI asociado si otra parte razonablemente que va a crear un vnculo de hipertexto que, hacer o refutar afirmaciones acerca de, recuperar o cach una representacin de la misma, incluir todos o parte de ella por referencia en otra representacin, anote o realizar otras operaciones en ellos. Los desarrolladores de software deben esperar que compartir URIs en aplicaciones ser til, incluso si la utilidad no es evidente al principio. La etiqueta "URIs, direccionamiento y el uso de HTTP GET y POST" explica beneficios adicionales y consideraciones de direccionamiento de URI. Nota: Algunos usos de sistemas (como el "ftp" especificacin del esquema URI) de URI el trmino "designar" en este documento utiliza "identificar".

2.2. Relaciones URI y de recursos

Por diseo un URI identifica un recurso. No limitar el alcance de lo que podra ser un recurso. El trmino "recursos" se utiliza en un sentido general de lo que podra identificarse mediante un URI. Es convencional en el hipertexto Web para describir las pginas Web, imgenes, catlogos de productos, etc. como "recursos". La caracterstica distintiva de estos recursos es que todas sus caractersticas esenciales pueden transmitir un mensaje. Identificamos este conjunto como "recursos de informacin". Este documento es un ejemplo de una fuente de informacin. Compuesta de palabras y smbolos de puntuacin y otros artefactos que pueden codificarse, con diversos grados de fidelidad, en una secuencia de bits y grficos. No hay nada sobre el contenido de la informacin esencial de este documento que en principio no puede ser transferido en un mensaje. En el caso de este documento, la carga de mensaje es la representacin de este documento. Sin embargo, nuestro uso de los recursos del trmino es intencionalmente ms amplio. Otras cosas, tales como automviles y perros (y, si has imprimir este documento en fsicas hojas de papel, el artefacto que estn sosteniendo en su mano), son recursos demasiado. Son no los recursos de informacin, sin embargo, debido a que su esencia no es informacin. Aunque es posible describir muchas cosas acerca de un automvil o un perro en una secuencia de bits, la suma de esas cosas siempre ser una aproximacin del carcter esencial de los recursos. Se define el trmino "recurso de informacin" porque observamos que es til en los debates de la tecnologa Web y puede ser til en la construccin de las especificaciones para las instalaciones construidas para uso en el Web.

Restriccin: URI identificar un nico recurso Asignar a identificadores URI distinta a los distintos recursos. Desde el mbito de un URI es global, el recurso identificado por un URI no depende del contexto en el que el identificador URI aparece (vase tambin la seccin sobre identificacin indirecta (2.2.3)). [URI] es un acuerdo sobre cmo la comunidad de Internet asigna los nombres y las asocia con los recursos que se identifican. URI se dividen en esquemas (2.4) que definen, a travs de la especificacin del esquema, el mecanismo por el cual estn asociados con recursos identificadores especficos del plan. Por ejemplo, el esquema URI "http" ([RFC2616]) utiliza servidores DNS y HTTP basado en TCP con el fin de la asignacin del identificador y resolucin. Como resultado, los identificadores, como "http://example.com/somepath#someFrag" suelen tener significado a travs de la experiencia comunitaria de realizar una solicitud HTTP GET en el identificador y, si se les da una respuesta satisfactoria, interpretar la respuesta como una representacin del recurso identificado. (Vase tambin el Fragmento identificadores (2.6).) Por supuesto, una accin de recuperacin como GET no es la nica manera de obtener informacin acerca de un recurso. Uno tambin podra publicar un documento que pretende definir el significado de un identificador URI especfico. Estas otras fuentes de informacin pueden sugerir significados para dichos identificadores, pero es una decisin poltica local si esas sugerencias deben ser atendidas. Como uno podra desear para referirse a una persona por distintos nombres (por nombre completo, nombre slo, apodo de deportes, apodo romntico y as sucesivamente), arquitectura Web permite la Asociacin de ms de un URI con un recurso. URIs que identifican el mismo recurso se denominan alias URI. La seccin de alias de URI (2.3.1) describe algunos de los costes potenciales de crear a URIs mltiples para el mismo recurso. Varias secciones de este documento abordan preguntas acerca de la relacin entre URI y recursos, incluyendo: Cunto puedo decir acerca de un recurso por la inspeccin de un URI que identifica? Consulte las secciones sobre esquemas de URI (2.4) y opacidad URI (2.5). Quin determina qu recurso un URI identifica? Consulte la seccin sobre la asignacin de URI (2.2.2). Puede el recurso identificado por un cambio URI en el tiempo? Consulte las secciones sobre la persistencia de URI (3.5.1) y la administracin de representacin (3.5). Ya ms de un URI puede identificar el mismo recurso, cmo puedo saber qu URIs identificar el mismo recurso? Consulte las secciones sobre la comparacin URI (2.3) y afirmaciones que dos URIs identificar el mismo recurso (2.7.2). 2.2.1. Colisin de URI Por diseo, un URI identifica un recurso. Utilizando el mismo URI para identificar directamente recursos diferentes, produce una colisin de URI. Colisin a menudo impone un costo de comunicacin debido a que el esfuerzo necesario para resolver ambigedades. Supongamos, por ejemplo, que una organizacin hace uso de un URI para referirse a la pelcula El golpe, y otra organizacin utiliza el mismo URI para referirse a un foro de discusin sobre El golpe. A un tercero, consciente de ambas organizaciones,

esta colisin crea confusin sobre lo que identifica la direccin URI, socavando el valor del identificador URI. Si uno quera hablar acerca de la fecha de creacin del recurso identificado por el URI, por ejemplo, no sera claro si esto significaba "cuando se cre la pelcula" o "cuando se cre el Foro de discusin sobre la pelcula." Soluciones sociales y tcnicas se han ideado para ayudar a evitar la colisin de URI. Sin embargo, el xito o el fracaso de estos diferentes enfoques depende del grado en que existe consenso en la comunidad de Internet en acatar las especificaciones definen. La seccin sobre la asignacin de URI (2.2.2) examina los criterios para establecer la fuente autorizada de informacin acerca de qu recursos a URI identifica. URI se utilizan a veces para identificacin indirecta (2.2.3). Esto no necesariamente conduce a colisiones. 2.2.2. Asignacin de URI Asignacin de URI es el proceso de asociar un identificador URI a un recurso. Asignacin puede realizarse por los propietarios de recursos y por otras partes. Es importante evitar la colisin de URI (2.2.1). 2.2.2.1. Propiedad URI Propiedad URI es una relacin entre un URI y una entidad social, como una persona, organizacin o especificacin. Propiedad URI da la entidad social relevante ciertos derechos, incluyendo: 1. para pasar sobre la propiedad de algunos o todos propiedad URI a otro titular: delegacin; y 2. para asociar un recurso con una propiedad URI: asignacin de URI. Por convencin social, propiedad URI se delega en el registro de esquema URI IANA [IANASchemes], s una entidad social, las especificaciones de esquema URI registrados de IANA. Algunas especificaciones de esquema URI adems delegan propiedad registros subordinados o a otros propietarios designados, quien podrn delegar ms propiedad. En el caso de una especificacin, propiedad en ltima instancia corresponde a la comunidad que mantiene la especificacin. El enfoque adoptado para el esquema URI "http", por ejemplo, sigue el patrn por el cual la comunidad de Internet delega autoridad, a travs del registro del esquema URI de IANA y el DNS, sobre un conjunto de identificadores URI con un prefijo comn a un propietario particular. Una consecuencia de este enfoque es la fuerte dependencia de la Web en el registro central de DNS. Se adopta un enfoque diferente por el sistema de URNA sintaxis [RFC2141] que delega propiedad de porciones del espacio URN URN Namespace especificaciones que estn registrados en un registro mantenido IANA de URNA Namespace identificadores. URI propietarios son responsables de evitar la asignacin de URI equivalente a varios recursos. Por lo tanto, si una especificacin del esquema URI proporcionar para la delegacin de conjuntos individuales o organizadas de URI, debera tener dolores para garantizar que la propiedad en ltima instancia reside en manos de una sola entidad social. Permitir que a mltiples propietarios aumenta la probabilidad de colisiones de URI. URI propietarios pueden organizar o implementar infrastruture para asegurarse de que las representaciones de recursos asociados estn disponibles y, cuando proceda, interaccin con el recurso es posible a travs del intercambio de representaciones. Hay expectativas sociales para responsable Gestin de representacin (3.5) por los propietarios URI. Implicaciones sociales adicionales de propiedad URI no se describen aqu. Consulte la etiqueta cuestin siteData-36, que se refiere a la expropiacin de autoridad de nombres. 2.2.2.2. Otros esquemas de asignacin Algunos esquemas de utilizan tcnicas distintas de propiedad delegada para evitar la colisin. Por ejemplo, la especificacin para el esquema de URL (sic) de datos [RFC2397] especifica que el recurso identificado por una combinacin de datos URI tiene slo una representacin posible. Los datos de representacin es el URI que identifica a ese recurso. Por lo tanto, la especificacin propia determina cmo se asignan los datos URI; ninguna delegacin es posible. Otros sistemas (como "news:comp.text.xml") se basan en un proceso social. 2.2.3. Identificacin indirecta Decir que el URI "mailto:nadia@example.com" identifica tanto un buzn de correo de Internet y Nadia, la persona presenta una colisin de URI. Sin embargo, podemos utilizar el identificador URI para identificar indirectamente Nadia. Los identificadores se utilizan en esta forma. Escuchar una emisin de noticias, uno puede escuchar un informe sobre Gran Bretaa que comienza ", 10 de Downing Street anunci hoy una serie de nuevas medidas econmicas." En general, "nmero 10 de Downing Street" identifica la residencia oficial del primer ministro britnico. En este contexto, el reportero de noticias est usando (como retrica ingls permite) para identificar indirectamente el Gobierno britnico. Asimismo, URIs identificar recursos, pero tambin se puede utilizar en muchas construcciones indirectamente identificar otros recursos. Polticas de asignacin global aprobado que algunos URI llamativo como identificadores de propsito generales. Poltica local establece indirectamente identifican. Supongamos nadia@example.com es la direccin de correo electrnico de Nadia. Los organizadores de una Conferencia asiste Nadia podran utilizar "mailto:nadia@example.com" para referirse indirectamente a ella (por ejemplo, utilizando el identificador URI como una clave de base de datos en su base de datos de participantes en la Conferencia). Esto no introduce una colisin de URI.

2.3. Comparaciones URI

URI que son idnticas, de carcter por carcter, se refieren al mismo recurso. Dado que la arquitectura Web permite la Asociacin de mltiples URI con un determinado recurso, dos identificadores URI que no son de carcter por carcter idntico mayo todava se refieren al mismo recurso. URI diferentes no necesariamente se refieren a diferentes recursos, pero generalmente es un mayor coste computacional para determinar que URI diferentes hacen referencia al mismo recurso. Para reducir el riesgo de un falso negativo (es decir, un incorrecto concluir que dos identificadores URI no se refieren al mismo recurso) o un falso positivo (es decir, un incorrecto concluir que dos URIs hacen referencia al mismo recurso), algunas especificaciones describen pruebas de equivalencia a comparacin de carcter por carcter. Agentes que llegan a conclusiones basadas en comparaciones que no estn autorizadas por las especificaciones pertinentes asumir la responsabilidad por cualquier problema que como resultado; Consulte la seccin sobre el tratamiento de errores (5.3) para obtener ms informacin acerca de un comportamiento responsable al llegar a conclusiones sin licencia. 6 De la seccin de [URI] proporciona ms informacin sobre la comparacin de URI y reducir el riesgo de falsos negativos y positivos. Vase tambin la afirmacin de que dos URIs identificar el mismo recurso (2.7.2). 2.3.1. Alias URI Aunque hay beneficios (como nombres de flexibilidad) al alias URI, tambin estn los costos. URI alias son perjudiciales cuando divide la Web de recursos relacionados. Un corolario del principio de Metcalfe (el "efecto de red") es que el valor de un recurso determinado puede medirse por el nmero y el valor de otros recursos en su entorno de red, es decir, los recursos que se vinculan a ella. El problema con alias es que si la mitad del barrio apunta a un URI de un recurso determinado y los otros puntos de la mitad a un URI en segundo lugar, diferente para el mismo recurso, el barrio est dividido. No slo es el recurso de un alias infravalorada debido a esta divisin, el barrio entero de recursos pierde valor debido a las faltantes relaciones de segundo orden que deben existir entre los recursos de referencia en virtud de sus referencias a los recursos de un alias.

Buena prctica: evita URI alias El propietario de un URI no debe asociar a URIs arbitrariamente diferentes con el mismo recurso. Los consumidores URI tambin tienen un papel en garantizar la coherencia URI. Por ejemplo, cuando se transcribe un URI, agentes deberan no gratuitamente por ciento-codificar caracteres. El trmino "personaje" se refiere a personajes URI, como se define en la seccin 2 del [URI]; codificacin por ciento se explica en la seccin 2.1 de dicha especificacin.

Buena prctica: uso de URI consistente Un agente que recibe un URI debe referirse al recurso asociado con el mismo identificador URI, carcter por carcter. Cuando un URI alias son moneda comn, el propietario URI debe utilizar tcnicas de protocolo como servidor redirige a relacionar los dos recursos. Los beneficios de la Comunidad cuando el propietario URI admite la redireccin de un alias URI al URI "oficial" correspondiente. Para obtener ms informacin sobre redireccin, consulte la seccin 10.3, redireccin, en [RFC2616]. Vase tambin [CHIPS] para una discusin de algunas prcticas ptimas para los administradores del servidor. 2.3.2. Reutilizacin de representacin Suavizado URI slo se produce cuando ms de un URI se utiliza para identificar el mismo recurso. El hecho de que diferentes recursos a veces tienen la misma representacin no hace el URI de los alias de recursos.

Historia Dirk le gustara aadir un vnculo desde su sitio Web a la pgina del tiempo de Oaxaca. Utiliza el identificador URI http://weather.example.com/oaxaca y etiquetas su vnculo "informe sobre el clima en Oaxaca el 01 de agosto de 2004". Nadia seala a Dirk que l es establecer expectativas engaosas para el URI ha utilizado. La poltica de sitio de clima de Oaxaca es que el URI en cuestin identifica un informe sobre el clima actual en Oaxaca, en cualquier da dado y no el clima el 1 de agosto. Por supuesto, el primero de agosto de 2004, enlace de Dirk ser correcta, pero el resto del tiempo va ser engaosa a lectores. Nadia seala a Dirk que los administradores del sitio de clima de Oaxaca que est disponibles un URI diferente permanentemente asignadas a un recurso de informes sobre el clima en 01 de agosto de 2004. En esta historia, hay dos recursos: "un informe sobre el clima actual en Oaxaca" y "un informe sobre el clima en Oaxaca el 01 de agosto de 2004". Los administradores del sitio de clima Oaxaca asignan a dos identificadores URI a estos dos recursos. El 01 de agosto de 2004, las representaciones de estos recursos son idnticas. Ese hecho que eliminar la referencia URI diferentes dos produce representaciones idnticas no implica que el URI dos son alias.

2.4. Esquemas de URI

En el identificador URI "http://weather.example.com/", "http" que aparece antes de los dos puntos (":") nombra un esquema URI. Cada esquema URI tiene una especificacin que explica los detalles especficos del plan de cmo asignar y convertirse en asociado a un recurso de identificadores de esquema. La sintaxis URI as es un sistema de nomenclatura federado y

extensible en especificacin de cada plan puede restringir an ms la sintaxis y la semntica de identificadores dentro de ese esquema. Ejemplos de URI de diversos planes incluyen: mailto e@example.o :Jo rg FTP://example.o rg/aDirectory/aFile News:co mp.Info systems.www Tel: + 1-816-555-1212 LDAP://LDAP.example.org/c=GB?objectClass?One urn:oasis:names:tc:entity:xmlns:xml:catalog

Mientras que la arquitectura Web permite la definicin de nuevos esquemas, introduciendo un nuevo esquema es costoso. Una gran cantidad de software implementado ya procesos a URIs de esquemas cono cido y muchos aspecto del s s procesamiento de URI dependen de la combinacin. Intro duccin de un nuevo esquema URI requiere el desarrollo y despliegue del software cliente para manejar el sistema, sino tambin de agentes auxiliares tales como puertas de enlace, s n servidores pro y almacena en cach. Consulte [RFC2718] para otras consideraciones y los costos relacionado co el xy diseo del esquema URI. Debido a esto co s stes, si existe una combinacin de URI que satisface las necesidades de una aplicacin, diseadores deberan usarlo en lugar de inventar una.

Buenas prcticas: esquemas de URI reutilizar Una especificacin debe vo lver a utilizar un esquema URI existente (en lugar de crear uno nuevo) cuando proporcio las propiedades deseadas de identificadores y su relacin con los recursos. na Considerar nuestro escenario de viajes: debe el agente proporcio info na rmacin sobre el clima en registro de Oaxaca un nuevo esquema URI "tiempo para la identificacin de recursos relacio " nados con el clima? Entonces podra publicar a URIs como "weather://travel.example.com/oaxaca". Cuando un agente de software referencias URI, si lo que realmente sucede es HTTP GET se invoca para recuperar una representacin del recurso ento , nces un "http" URI habra bastado. 2.4.1. Registro de esquema URI La auto ridad de nmeros asignados de Internet (IANA) mantiene un registro [IANASchemes] de las asignaciones entre nombres de esquema URI y especificaciones del sistema. Po ejemplo, el registro de la IANA indica que el esquema de "http" r est definido en [RFC2616]. El pro ceso para registrar un nuevo esquema de URI est definido en [RFC2717]. Esquemas de URI no registrados no deben utilizarse para una serie de razones: No hay ninguna manera generalmente aceptada para localizar la especificacin del esquema. Alguien puede estar usando el esquema para otros fines. Uno no debe esperar que so ftware de pro psito general har algo til con URI de este esquema ms all de la comparacin URI. Es una motivacin equivocada para registrar un nuevo esquema URI permitir que un agente de so ftware iniciar una aplicacin en particular cuando se recupera una representacin. Lo mismo puede lograrse a expensas de baja enviando en su lugar el tipo de la representacin, permitiendo el uso de protocolos de transferencia existentes e implementacio nes. Incluso si un agente no puede pro cesar dato de representacin en un fo s rmato desco nocido, al meno puede recuperar. Los s datos pueden contener informacin suficiente para permitir a un usuario o un agente de usuario hacer algn uso de ella. Cuando un agente no manejar un nuevo esquema URI, no se puede recuperar una representacin. Al disear un nuevo formato de datos, el mecanismo preferido para promover su despliegue en la Web es la Internet tipo multimedia (co nsulte tipos de representacin y tipo de medios de Internet (3.2)). Tipo de medio tambin propo s s s rcionan un medio para la construccin de nuevas so licitudes de info rmacin, tal co se describe en las orientacio mo nes futuras de fo rmatos de dato (4.6). s

2.5. Opacidad URI

Es tentador para adivinar la naturaleza de un recurso por la inspeccin de un URI que lo identifica. Sin embargo, la Web est diseado para que agentes comunicarn el estado de info rmacin de recursos a travs de representaciones, no de identificadores. En general, uno no puede determinar el tipo de una representacin de recursos mediante la inspeccin de un URI para ese recurso Por ejemplo, el ".html" al final del "http://example.com/page.html" no ofrece ninguna garanta de que las . representaciones de los recursos identificados se beneficiarn con el tipo de medio de Internet "text/html". El editor es libre para asignar identificadores y definir cmo se sirven. El protocolo HTTP no restringir el tipo de medios de co municacin de Internet basado en el compo nente de trazado del identificador URI; el propietario URI es libre para co nfigurar el servidor para devo lver una representacin con PNG o cualquier otro formato de dato s. Estado del recurso puede evolucio nar con el tiempo. Que requieren de un propietario URI publicar un nuevo identificador URI para cada cambio en el estado del recurso dara lugar a un nmero significativo de referencias ro tas. Para ro bustez, arquitectura Web pro mueve la independencia entre un identificador y el estado del recurso identificado.

Buenas prcticas: opacidad URI

Agentes haciendo uso de identificadores URI no debe intentan deducir las propiedades de los recursos que se hace referencia. En la prctica, un pequeo nmero de inferencias es posible porque ellos tienen licencia explcitamente por las especificaciones pertinentes. Algunas de estas deducciones se discuten los Detalles de recuperar una representacin (3.1.1). El ejemplo URI utilizado en el escenario de viajes ("http://weather.example.com/oaxaca") sugiere que un lector humano que el recurso identificado tiene algo que ver con el clima en Oaxaca. Un sitio el tiempo en Oaxaca podra identificarse facilmente por el URI "http://vjc.example.com/315". Y el URI "http://weather.example.com/vancouver" podra identificar el recurso "mi lbum de fotos". Por otro lado, el URI "mailto:joe@example.com" indica que el URI se refiere a un buzn de correo. La especificacin del esquema URI "mailto" autoriza a los agentes para inferir que URI de esta forma identificar buzones de correo de Internet. Algunas autoridades de asignacin de URI del documento y publican sus polticas de asignacin de URI. Para obtener ms informacin acerca de opacidad URI, vase etiqueta cuestiones metaDataInURI-31 y 36 siteData.

2.6. Fragmento de identificadores

Historia Al examinar el documento XHTML que Nadia recibe como una representacin del recurso identificado por "http://weather.example.com/oaxaca", descubre que el URI "http://weather.example.com/oaxaca#weekend" se refiere a la parte de la representacin que transmite informacin acerca de las perspectivas de fin de semana. Este identificador URI incluye el identificador de fragmento fin de "semana" (la cadena tras el "#"). El componente de identificador de fragmento de un URI permite identificacin indirecta de un recurso secundario por referencia a un recurso primario y la informacin de identificacin adicional. El recurso secundario puede ser alguna parte o subconjunto del principal recurso, alguna opinin sobre representaciones del principal recurso, o algn otro recurso definido o descrito por esas representaciones. Los trminos "principal recursos" y "secundaria" se definen en la seccin 3.5 de [URI]. Los trminos "primarios" y "secundarios" en este contexto no limitan la naturaleza del recurso, no son las clases. En este contexto, primaria y secundaria simplemente indican que existe una relacin entre los recursos a los efectos de un URI: el URI con un identificador de fragmento. Cualquier recurso puede ser identificado como un recurso secundario. Tambin pueden identificarse mediante un URI sin un identificador de fragmento y un recurso puede ser identificado como un recurso secundario a travs de mltiples URIs. El propsito de estas condiciones es permitir la discusin de la relacin entre los recursos, no para limitar la naturaleza de un recurso. La interpretacin de los identificadores de fragmento se explica en la seccin sobre los tipos de medios de comunicacin y semntica de identificador de fragmento (3.2.1). Consulte la etiqueta cuestin abstractComponentRefs-37, que se refiere al uso de identificadores de fragmento con nombres de espacio de nombres para identificar componentes abstractos.

2.7. Orientaciones futuras de identificadores

Quedan preguntas abiertas sobre identificadores en la Web. 2.7.1. Identificadores internacionalizados La integracin de los identificadores internacionalizados (es decir, compuesta de caracteres ms all de las permitidas por [URI]) en la Web la arquitectura es un asunto importante y abierto. Consulte la etiqueta nmero IRIEverywhere-27 para discusin sobre trabajo va en esta rea. 2.7.2. Afirmacin que dos URIs identificar el mismo recurso Emergentes Web semntica tecnologas, incluyendo el "Web ontologa idioma (OWL)" [OWL10], definen las propiedades de RDF como sameAs para afirmar que dos URIs identificar el mismo recurso o inverseFunctionalProperty a entenderlo.

3. Interaccin
Comunicacin entre los agentes en una red de recursos implica URIs, mensajes y datos. Protocolos de Internet (como HTTP, FTP, NNTP, SMTP y jabn) se basan en el intercambio de mensajes. Puede incluir un mensaje de datos, as como metadatos acerca de un recurso (por ejemplo, los encabezados HTTP "Vary" y "Alterna"), los datos del mensaje y el mensaje en s (por ejemplo, el encabezado HTTP "Transfer-encoding"). Un mensaje incluso puede incluir metadatos acerca de los metadatos de mensaje (para las comprobaciones de integridad del mensaje, por ejemplo).

Historia Nadia sigue un vnculo de hipertexto con la etiqueta "imagen satelital" a la espera de recuperar una foto de satlite de la regin de Oaxaca. El enlace a la imagen de satlite es un vnculo XHTML codificado como <a href="http://example.com/satimage/oaxaca">satellite image</a>. Navegador de Nadia analiza el URI y determina que su rgimen es "http". La configuracin del navegador determina cmo localiza la informacin

identificada, que podra ser mediante un cach de las acciones de recuperacin previa, pngase en contacto con un intermediario (como un servidor proxy), o por acceso directo al servidor identificado por una porcin del identificador URI. En este ejemplo, el navegador abre una conexin de red al puerto 80 en el servidor "ejemplo.com" y enva un mensaje de "GET" tal como se especifica en el protocolo HTTP, solicitando una representacin del recurso. El servidor enva un mensaje de respuesta al navegador, nuevo acuerdo con el protocolo HTTP. El mensaje consta de varias cabeceras y una imagen JPEG. El navegador lee los encabezados, aprende del campo "Content-Type" que el tipo de medios de comunicacin de Internet de la representacin es "image/jpeg", lee la secuencia de octetos que componen los datos de representacin, y procesa la imagen. Esta seccin describe los principios arquitectnicos y restricciones en cuanto a las interacciones entre los agentes, incluyendo temas como protocolos de red y estilos de interaccin, junto con las interacciones entre la Web como un sistema y las personas que hacen usan de ella. El hecho de que la Web es un sistema altamente distribuido afecta a limitaciones arquitectnicas y suposiciones acerca de las interacciones.

3.1. Mediante un URI para acceder a un recurso

Agentes pueden utilizar un URI para tener acceso al recurso de referenciado; Esto se denomina eliminar la referencia URI. Acceso puede adoptar muchas formas, incluida la recuperacin de una representacin del recurso (por ejemplo, mediante el uso de HTTP GET o cabeza), agregar o modificar una representacin del recurso (por ejemplo, mediante el uso de HTTP POST o PUT, que, en algunos casos, puede cambiar el estado actual del recurso si las representaciones presentadas son interpretadas como instrucciones para ello) y eliminar algunas o todas las representaciones del recurso (por ejemplomediante el uso de HTTP eliminar, que en algunos casos puede resultar en la eliminacin del propio recurso). Puede haber ms de una forma de acceso a un recurso para un determinado URI; contexto de aplicacin determina el mtodo de acceso que se utiliza un agente. Por ejemplo, un navegador puede utilizar HTTP GET para recuperar una representacin de un recurso, mientras que un comprobador de enlaces hipertexto podra utilizar HTTP HEAD en el mismo URI simplemente para establecer si una representacin est disponible. Algunos esquemas URI las expectativas acerca de los mtodos de acceso disponibles, otros (por ejemplo, el esquema de URNA [RFC 2141]) no. Punto 1.2.2 de [URI] trata sobre la separacin de la identificacin y la interaccin con ms detalle. Para obtener ms informacin acerca de las relaciones entre varios mtodos de acceso y capacidad de direccionamiento URI, ver la etiqueta "URIs, direccionamiento y el uso de HTTP GET y POST". Aunque muchos esquemas de URI (2.4) se nombran protocolos, esto no implica que uso de tal URI resultar necesariamente en el acceso al recurso mediante el protocolo con nombre. Incluso cuando un agente utiliza un URI para recuperar una representacin, que podra ser el acceso a travs de puertas de enlace, servidores proxy, cachs y servicios de resolucin de nombres que son independientes del protocolo asociado con el nombre de esquema. Muchos esquemas de URI definen un protocolo de interaccin predeterminado para intentar el acceso a los recursos identificados. Ese Protocolo de interaccin suele ser la base para la asignacin de identificadores dentro de ese esquema, slo como "http" URI se definen en trminos de servidores HTTP basado en TCP. Sin embargo, esto no implica que toda la interaccin con esos recursos se limita al protocolo predeterminado de interaccin. Por ejemplo, recuperacin de informacin, sistemas a menudo hacen uso de proxies interactuar con multitud de esquemas de URI, como proxies HTTP se utiliza para tener acceso a recursos "ftp" y "wais". Servidores proxy puede tambin proporcionar mejores servicios, tales como proxies de anotacin que combinan la recuperacin de informacin normal con recuperacin de metadatos adicionales para proporcionar una vista transparente, multidimensional de recursos utilizando los mismos protocolos y los agentes de usuario como la Web no anotado. Asimismo, pueden definirse protocolos futuros que abarcan nuestros sistemas actuales, utilizando mecanismos de interaccin completamente diferente, sin cambiar los esquemas existentes de identificador. Vase tambin, principio de especificaciones ortogonales (5.1). 3.1.1. Detalles de recuperar una representacin Eliminar la referencia URI generalmente implica una sucesin de pasos, como se describe en las especificaciones mltiples e implementado por el agente. El ejemplo siguiente ilustra la serie de especificaciones que rige el proceso cuando un agente de usuario es instruido para seguir un enlace de hipertexto (4.4) que es parte de un documento SVG. En este ejemplo, el identificador URI es "http://weather.example.com/oaxaca" y el contexto de aplicacin exige el agente de usuario recuperar y procesar una representacin del recurso identificado. 1. Puesto que el URI es parte de un enlace de hipertexto en un documento SVG, la primera especificacin pertinente es la recomendacin de SVG 1.1 [SVG11]. Seccin 17.1 de esta especificacin importa la semntica de vnculo definida en XLink 1.0 [XLink10]: "el recurso remoto (el destino del vnculo) se define mediante un URI especificado por el atributo href XLink 'a' elemento". La especificacin SVG va recuperar al Estado que implica la interpretacin de a a una representacin de un recurso, identificado por el atributo href del espacio de nombres XLink: "Mediante la activacin de estos vnculos (pulsando con el ratn, teclado, comandos de voz, etc.), los usuarios pueden visitar estos recursos". 2. La especificacin de XLink 1.0 [XLink10], que define el atributo href en seccin 5.4, afirma que "el valor del atributo href debe ser una referencia de identificador URI definido en [IETF RFC 2396], o debe traducirse en una referencia de identificador URI despus de que se aplique el procedimiento de escape que se describe a continuacin". 3. La especificacin de URI [URI] afirma que "cada URI comienza con un nombre de esquema que se refiere a una especificacin para asignar identificadores dentro de ese esquema". El nombre del esquema URI en este ejemplo es "http". 4. [IANASchemes] afirma que el esquema de "http" es definido por la especificacin de HTTP/1.1 (RFC 2616 [RFC2616], seccin 3.2.2). 5. En este contexto SVG, el agente construye una solicitud HTTP GET (cada seccin 9.3 de [RFC2616]) para recuperar la representacin. 6. 6 De la seccin de [RFC2616] define cmo el servidor crea un mensaje de respuesta correspondientes, incluido el campo de tipo de contenido.

7. Seccin 1.4 de [RFC2616] afirma "comunicacin HTTP suele tener lugar a travs de conexiones TCP/IP". En este ejemplo se refiere ese paso en el proceso ni otras medidas tales como la resolucin del sistema de nombres de dominio (DNS). 8. El agente interpreta la representacin devuelta de acuerdo con la especificacin de formato de datos que co rrespo nde a Tipo de medio de Internet (3.2) (el valor del tipo de co ntenido HTTP) en el registro pertinente de la IANA [MEDIATYPEREG de la representacin]. Precisamente qu representatio n(s) se recupera depende de varios facto res, incluyendo: 1. Si el pro pietario URI po a disposicin las representacio ne nes en absoluto; 2. Si el agente que hace la solicitud tiene privilegios de acceso para las representaciones (co nsulte la seccin so bre vinculacin y control (3) de acceso); 3. Si el pro pietario URI ha propo rcionado ms de una representacin (en diferentes fo rmatos tales como HTML, PNG o RDF; en diferentes idiomas como el espaol e ingls; o transfo rmado dinmicamente de acuerdo con las capacidades de hardware o software del destinatario la representacin resultante puede depender de negociacin entre el agente ), de usuario y el servido r. 4. El momento de la solicitud; el mundo cambia co el tiempo, por lo que las representaciones de los recursos tambin n puedan cambiar co el tiempo. n Supo niendo que se haya recuperado satisfacto riamente una representacin, la fuerza expresiva del fo rmato de representacin afectar cmo precisamente el proveedo de representacin comunica el estado del recurso Si la r . representacin comunica el estado del recurso inco rrectamente, esta inexactitud o ambigedad puede pro vocar confusin entre lo usuarios sobre lo que es el recurso Si lo usuarios diferentes llegan a conclusiones diferentes so s . s bre lo que es el recurso puede interpretar esto co una co , mo lisin de URI (2.2.1). Algunas comunidades, co el desarrollo de la Web mo semntica, tratan de proporcio nar un marco para co municarse con precisin la semntica de un recurso en una mquina de fo rma legible. Semntica legible por mquina puede aliviar alguno de la ambigedad asociada con lenguaje natural s descripcio nes de recursos.

3.2. Tipos de representacin y tipos de medios de Internet

Una representacin es dato que codifica la informacin sobre el estado del recurso. Representaciones no necesariamente s describen el recurso o retratar una semejanza del recurso o representar el recurso en o s sentido de la palabra , tro s "representar". Representaciones de un recurso pueden ser enviadas o recibieron mediante los protoco de interaccin. Estos pro colo a los to s su vez determinan la fo rma en que se transmiten las representaciones en la Web. HTTP, por ejemplo, prev para la transmisin de las representaciones co secuencias de octetos escribir utilizando tipos de medios de Internet [RFC2046]. mo As como es importante vo lver a esquemas de URI existentes siempre que sea posible, hay importantes beneficio a la s utilizacin de medios de co municacin escriban secuencias de octetos para representacio nes incluso en el caso inusual cuando un nuevo esquema URI y protocolo asociado es definirse. Por ejemplo, si el tiempo de Oaxaca se transmitieron al navegador de Nadia utilizando un protocolo distinto de HTTP, entonces software para procesar fo rmatos como texto/xhmtl + xml y image/png seguira siendo utilizable si el nuevo protocolo admite la transmisin de dicho tipos. Este es un ejemplo del s principio de especificaciones ortogo nales (5.1).

Buenas prcticas: reutilizar formatos de representacin Nuevos protoco creados para la Web debe transmiten representacio los nes como secuencias de o cteto escritos s por tipo de medios de Internet. s El mecanismo de tipo de medios de Internet tienen algunas limitaciones. Po ejemplo, las cadenas de tipo de medios de r comunicacin no admiten versiones (4.2.1) u otros parmetros. Consulte la etiqueta cuestiones uriMediaType-9 y 45 mediaTypeManagement que se refieren a aspectos del mecanismo de tipo de medios de co municacin. 3.2.1. Tipos de representacin y semntica de identificador de fragmento El tipo de medio de comunicacin de Internet define la sintaxis y la semntica del identificador de fragmento (introducido en s Identificadores de fragmento (2.6)), si alguna, que puede utilizarse junto co una representacin. n

Historia En una de sus pginas XHTML, Dirk crea un vnculo de hipertexto con una imagen que Nadia ha publicado en la Web. Crea un vnculo de hipertexto co <a href="http://www.example.com/images/nadia#hat">Nadia's hat</a>. n Emma vistas de pgina XHTML de Dirk en su navegado Web y sigue el enlace. La aplicacin HTML en su r explorador quita el fragmento de la URI y pide la imagen "http://www.example.com/images/nadia". Nadia sirve una representacin de SVG de la imagen (con el tipo de medio de Internet "imagen/svg + xml"). Navegado de Emma r inicia una implementacin de SVG para ver la imagen. Se pasa el URI original incluyendo el fragmento, "http://www.example.co m/images/nadia#hat" para esta aplicacin, causando una vista del sombrero para mostrarse en lugar de la imagen completa. Tenga en cuenta que la aplicacin HTML en el explorador de Emma no necesita entender la sintaxis y semntica de los SVG fragmentar (ni tiene la implementacin de SVG para entender HTML, WebCGM, RDF... fragmentar la sintaxis o semntica; simplemente tuvo que reco nocer la # delimiter de la sintaxis URI [URI] y quitar el fragmento al tener acceso a los recurso s). Esta o gonalidad (5.1) es una caracterstica impo rto rtante de la arquitectura Web; es lo que permiti explorador de Emma proporcio nar un servicio til sin necesidad de una actualizacin.

La semntica de un identificador de fragmento se define por el conjunto de representaciones que pudieran derivarse de una accin de recuperacin del recurso principal. El fragmento formato y resolucin son por lo tanto depende del tipo de una representacin potencialmente recuperado, a pesar de que esa recuperacin se realiza slo si el URI es desreferencia. Si dicha representacin no existe, entonces la semntica del fragmento es considera desconocido y, efectivamente, no restringida. Semntica de identificador de fragmento es ortogonal a esquemas de URI y as no puede definirse por las especificaciones de esquema URI. Interpretacin del identificador de fragmento se realiza nicamente por el agente de referencias de un URI; el identificador de fragmento no se pasa a otros sistemas durante el proceso de recuperacin. Esto significa que algunos intermediarios en arquitectura Web (como proxies) ninguna interaccin con identificadores de campo y esa redireccin (en HTTP [RFC2616], por ejemplo) no da cuenta de fragmentos. 3.2.2. Fragmento de identificadores y negociacin de contenido Negociacin de contenido se refiere a la prctica de hacer disponibles varias representaciones a travs de la misma direccin URI. Negociacin entre el agente requirente y el servidor determina que la representacin se sirve (por lo general con el objetivo de servir a la "mejor" representacin que puede procesar un agente receptor). HTTP es un ejemplo de un protocolo que permite a los proveedores de representacin a usar negociacin de contenido. Formatos de datos individuales pueden definir sus propias reglas para el uso de la sintaxis de identificador de fragmento para especificar diferentes tipos de subconjuntos, vistas o referencias externas que son identificables como recursos secundarios por ese tipo de medios de comunicacin. Por lo tanto, los proveedores de la representacin deben administrar contenido negociacin cuidadosamente cuando se utiliza con un URI que contiene un identificador de fragmento. Consideremos un ejemplo donde el propietario de la URI "http://weather.example.com/oaxaca/map#zicatela" usa negociacin de contenido para servir dos representaciones del recurso identificado. Pueden surgir tres situaciones: 1. La interpretacin de "zicatela" se define constantemente por ambas especificaciones de formato de datos. El proveedor de representacin decide cuando las definiciones del identificador de fragmento semntica es son suficientemente consistentes. 2. La interpretacin de "zicatela" se define de forma incoherente por las especificaciones de formato de datos. 3. La interpretacin de "zicatela" est definida en la especificacin de formato de uno datos pero no en el otro. La primera situacin: semntica coherente no plantea ningn problema. El segundo caso es un error de gestin de servidor: proveedores de representacin no deben usar negociacin de contenido para servir a los formatos de representacin que tienen semntica de identificador de fragmento inconsistente. Esta situacin tambin conduce a la colisin de URI (2.2.1). El tercer caso no es un error de gestin de servidor. Es un medio por el que puede crecer la Web. Debido a que la Web es un sistema distribuido en que formatos y agentes se implementan de forma no uniforme, arquitectura Web no restringir los autores slo utilizar formatos "mnimo comn denominador". Autores de contenido pueden beneficiarse de nuevos formatos de datos mientras todava asegura compatibilidad razonable para los agentes que an no se implementan. En el caso de tres, comportamiento por el agente receptor debe variar dependiendo de si el formato negociado define semntica de identificador de fragmento. Cuando un formato de datos recibidos no definir la semntica de identificador de fragmento, el agente no debe realizar la recuperacin de errores silenciosa a menos que el usuario haya dado su consentimiento; Consulte [CUAP] para comportamiento adicionales sugeridos en este caso. Ver relacionado TAG emitir RDFinXHTML 35.

3.3. Incoherencias entre la datos de representacin y metadatos

Comunicacin exitosa entre dos partes depende de un entendimiento razonable compartido de la semntica de los mensajes intercambiados, datos y metadatos. A veces, puede haber incongruencias entre los datos y metadatos del remitente de un mensaje. Ejemplos, observadas en la prctica, de inconsistencias entre la datos de representacin y metadatos incluyen: La codificacin de caracteres reales de una representacin (por ejemplo, "iso-8859-1", especificado por el atributo de encoding en una declaracin XML) es incompatible con el parmetro charset en los metadatos de representacin (por ejemplo, "utf-8", especificada por el campo de tipo de contenido en un encabezado HTTP). El espacio de nombres (4.5.3) del elemento raz de los datos de representacin XML (por ejemplo, segn lo especificado por el atributo "xmlns") es incompatible con el valor del campo tipo de contenido en un encabezado HTTP. Por otro lado, no hay ninguna incoherencia en sirviendo HTML contenido con el tipo de medios de comunicacin "text/plain", por ejemplo, ya que esta combinacin es licenciada por las especificaciones. Recibir agentes debe detectar inconsistencias de protocolo y realizar una adecuada recuperacin de errores.

Restriccin: inconsistencia de los datos de metadatos Agentes no deben ignorar los metadatos mensaje sin el consentimiento del usuario. As, por ejemplo, si los responsables de "weather.example.com" etiquetar errneamente la foto de satlite de Oaxaca como "image/gif" en lugar de "image/jpeg", y el explorador de Nadia detecta un problema, explorador de Nadia debe no ignorar el problema (por ejemplo, al simplemente representar la imagen JPEG) sin el consentimiento de Nadia. Navegador de Nadia puede notificar a Nadia del problema o notificar a Nadia y tomar las medidas correctivas.

Adems, los proveedores de representacin pueden ayudar a reducir el riesgo de incoherencias mediante una cuidadosa asignacin de metadatos de representacin (especialmente la que se aplica a travs de representaciones). La seccin sobre los tipos de medios para XML (4.5.7) presenta un ejemplo de reduccin del riesgo de error al no proporcionar metadatos acerca de codificacin al servir XML. La precisin de metadatos se basa en los administradores de servidor, los autores de las representaciones y el software que utilizan. Prcticamente, las capacidades de las herramientas y las relaciones sociales pueden ser factores limitantes. La exactitud de estos y otros campos de metadatos es tan importante para los recursos Web dinmicos, donde un poco de pensamiento y de programacin a menudo puede asegurar correcta metadatos para un gran nmero de recursos. A menudo hay una separacin de control entre los usuarios que crean representaciones de recursos y los administradores de servidor que mantienen el software del sitio Web. Dado que generalmente es el software del sitio Web que proporciona los metadatos asociados a un recurso, se deduce que la coordinacin entre los administradores de servidor y los creadores de contenido es obligatorio.

Buenas prcticas: Asociacin de metadatos Los administradores de servidor deben permiten que los creadores de representacin controlar los metadatos asociados con sus representaciones. En particular, los creadores de contenido necesitan para poder controlar el tipo de contenido (para la extensibilidad) y la codificacin de caracteres (para internacionalizacin adecuada). La etiqueta de encontrar "Metadatos autoritaria" describe con ms detalle cmo manejar la inconsistencia de los datos y metadatos y cmo puede utilizarse la configuracin del servidor para evitar que.

3.4. Interacciones seguras

Recuperacin de Nadia de informacin meteorolgica (un ejemplo de una consulta de slo lectura o bsqueda) califica como una "segura" interaccin; una interaccin segura es uno donde el agente no incurrir en ninguna obligacin ms all de la interaccin. Un agente puede incurrir en una obligacin a travs de otros medios (como con la firma de un contrato). Si un agente no tienen la obligacin antes una interaccin segura, no tiene esa obligacin despus. Otras interacciones Web se asemejan a los pedidos de ms de consultas. Estas interacciones inseguras puede causar un cambio en el estado de un recurso y el usuario puede se hace responsable de las consecuencias de estas interacciones. Interacciones inseguras incluyen suscribirse a un boletn, contabilizacin de una lista o modificar una base de datos. Nota: En este contexto, la palabra "insegura" no significa necesariamente "peligrosa"; se utiliza el trmino "seguro" en la seccin 9.1.1 de [RFC2616] y "inseguro" es el opuesto natural.

Historia Nadia decide reservar unas vacaciones a Oaxaca en "booking.example.com." Ella escribe datos en una serie de formularios en lnea y en ltima instancia se solicita informacin de tarjeta de crdito comprar los billetes de avin. Ella proporciona esta informacin de otra forma. Cuando presiona el botn "Comprar", su navegador abre otra conexin de red al servidor en "booking.example.com" y enva un mensaje compuesto por datos de formulario utilizando el mtodo POST. Se trata de una interaccin inseguro; Nadia desea cambiar el estado del sistema mediante el intercambio de dinero para los pasajes areos. El servidor lee la peticin POST, y despus de realizar la transaccin de reserva devuelve un mensaje al navegador de Nadia contiene una representacin de los resultados de la solicitud de Nadia. Los datos de representacin estn en XHTML para que pueda ser salvado o imprimirse para registros de Nadia. Tenga en cuenta que los datos transmitidos con el POST ni los datos recibidos en la respuesta necesariamente corresponden a cualquier recurso identificado mediante un URI. Interacciones seguras son importantes porque son las interacciones donde los usuarios pueden navegar con confianza y donde agentes (incluidos los motores de bsqueda y los exploradores que pre-cache los datos del usuario) pueden seguir vnculos de hipertexto con seguridad. Los usuarios (o agentes que actan en su nombre) no comprometerse a nada por consultar un recurso o un vnculo de hipertexto.

Principio: recuperacin segura Los agentes no contraer obligaciones por recuperar una representacin. Por ejemplo, es incorrecto para publicar un URI que, cuando sigui como parte de un enlace de hipertexto, suscribe un usuario a una lista de correo. Recuerda que los motores de bsqueda pueden seguir tales vnculos de hipertexto. El hecho de que es seguro HTTP GET, el mtodo de acceso que utiliza ms a menudo cuando siguiendo un enlace de hipertexto, no implica que todas las interacciones seguras deben hacerse a travs de HTTP GET. A veces, puede haber buenas razones (por ejemplo, los requisitos de confidencialidad o lmites prcticos en longitud URI) para llevar a cabo una operacin de otra manera segura mediante un mecanismo generalmente reservado para las operaciones de seguras (por ejemplo, HTTP POST).

Para obtener ms informacin acerca de las operaciones seguras y no seguras mediante HTTP GET y POST y el manejo de los problemas de seguridad en el uso de HTTP GET, ven la etiqueta "URIs, direccionamiento y el uso de HTTP GET y POST". 3.4.1. Rendicin de cuentas y las interacciones inseguras

Historia Nadia paga por sus billetes en lnea (a travs de una interaccin de POST como se describi anteriormente). Ella recibe una pgina Web con informacin de confirmacin y desea agregar a Favoritos lo por lo que ella puede hacer referencia a l cuando ella calcula sus gastos. Aunque Nadia puede imprimir los resultados o guardarlos en un archivo, tambin deseara agregar a Favoritos les. Solicitudes de transaccin y los resultados son recursos valiosos, y al igual que todos los recursos valiosos, es til poder referirse a ellos con un URI persistente (3.5.1). Sin embargo, en la prctica, Nadia no puede marcar su compromiso a pagar (expresada a travs de la solicitud POST) o la compaa area reconocimiento y compromiso que le prestara un vuelo (expresado a travs de la respuesta al envo). Hay maneras de proporcionar URI persistentes para las solicitudes de transaccin y sus resultados. Para las solicitudes de la transaccin, agentes de usuario pueden proporcionar una interfaz para administrar las transacciones donde el agente de usuario haya incurrido una obligacin en nombre del usuario. Resultados de la transaccin, HTTP permite a los proveedores de representacin asociar un identificador URI con los resultados de una peticin HTTP POST con el encabezado "ContentLocation" (descrito en la seccin 14.14 de [RFC2616]).

3.5. Gestin de representacin

Historia Dado que Nadia considera til la pgina del tiempo de Oaxaca, ella correos electrnicos de una revisin a su amigo Dirk recomendar que retira de 'http://weather.example.com/oaxaca'. Dirk hace clic en el vnculo de hipertexto resultante en el correo electrnico que recibe y se ve frustrado por un 404 (no encontrado). Dirk intenta nuevamente al da siguiente y recibe una representacin con "Noticias" que es de dos semanas viejo. Trata una vez ms al da siguiente slo para recibir una representacin que afirma que el tiempo en Oaxaca es soleado, a pesar de que le dicen sus amigos en Oaxaca por telfono que en realidad est lloviendo. Dirk y Nadia concluyen que los propietarios URI son poco fiables o impredecibles. Aunque el propietario URI ha elegido la Web como un medio de comunicacin, el dueo ha perdido a dos clientes gracias a la administracin ineficaz de representacin. El propietario de un URI puede suministrar cero o ms representaciones autorizadas del recurso identificado por ese URI. Hay un beneficio a la comunidad en la prestacin de representaciones.

Buenas prcticas: representacin disponible El propietario de un URI debe proporcionar representaciones del recurso que identifica Por ejemplo, los propietarios de URI de espacio de nombres XML deben utilizarlos para identificar un documento de espacio de nombres (4.5.4). Slo porque existen representaciones no significa que siempre es deseable para recuperarlos. De hecho, en algunos casos lo contrario es cierto.

Principio: referencia no implica la eliminacin de referencias Un autor de desarrollador o especificacin de aplicacin no debe requieren recuperacin en red de representaciones cada vez que se hace referencia. Eliminar la referencia URI tiene un costo (potencialmente significativo) en informtica y recursos de ancho de banda, puede tener implicaciones de seguridad y puede imponer una latencia significativa en la aplicacin dereferencing. Eliminar la referencia URI debe evitarse excepto cuando sea necesario. Las siguientes secciones tratan algunos aspectos de la gestin de representacin, incluida la promocin de la persistencia de URI (3.5.1), administracin de acceso a los recursos (3)y apoyar la navegacin (3.5.3). 3.5.1. Persistencia de URI Como ocurre con muchas de las interacciones humanas, confianza en las interacciones a travs de la Web depende de la estabilidad y la previsibilidad. Para un recurso de informacin, persistencia depende de la consistencia de las representaciones. El proveedor de representacin decide cuando representaciones son suficientemente consistentes (aunque esa determinacin generalmente toma en cuenta las expectativas del usuario).

Aunque persistencia en este caso es observable como resultado de la recuperacin de la representacin, el trmino utilizado para describir la propiedad deseable que, una vez asociado a un recurso, persistencia de URI URI debe continuar indefinidamente para referirse a ese recurso.

Buenas prcticas: representacin consistente El propietario de un URI debe proporcionar representaciones del recurso identificado consistente y predecible. Persistencia de URI es una cuestin de poltica y el compromiso por parte del propietario URI. La eleccin de un determinado esquema URI no proporciona ninguna garanta de que esos URIs ser persistente o que no van a ser persistentes. HTTP [RFC2616] ha sido diseado para ayudar a administrar la persistencia de URI. Por ejemplo, redireccin HTTP (utilizando los cdigos de respuesta 3xx) permite servidores para decirle a un agente que ms accin debe tomarse por el agente a fin de satisfacer la solicitud (por ejemplo, un nuevo URI es asociado con el recurso). Adems, negociacin de contenido tambin promueve la coherencia, como un administrador del sitio no es necesario definir nuevos URIs al agregar soporte para una nueva especificacin de formato. Protocolos que no admiten la negociacin de contenido (como FTP) requieren un nuevo identificador cuando se presenta un nuevo formato de datos. Uso indebido de negociacin de contenido puede conducir a representaciones inconsistentes. Para ms discusin sobre la persistencia de URI, consulte [Cool]. 3.5.2. Control de acceso y vinculacin Es razonable limitar el acceso a un recurso (por razones comerciales o de seguridad, por ejemplo), pero simplemente la identificacin de los recursos es como refirindose a un libro por el ttulo. En circunstancias excepcionales, personas pueden han acordado mantener ttulos o URIs confidencial (por ejemplo, el autor de un libro y un editor podrn acordar mantener el URI de la pgina que contiene material adicional en secreto hasta despus de que el libro es publicado), de lo contrario son libres canjearlos. Como una analoga: los propietarios de un edificio pueden tener una poltica que el pblico slo puede entrar en el edificio a travs de la puerta principal y slo durante las horas laborales. Las personas que trabajan en el edificio y que hacen entregas a ella podran utilizar otras puertas segn corresponda. Esa poltica se aplica mediante una combinacin de personal de seguridad y dispositivos mecnicos tales como bloqueos y tarjetas de pase. Uno no hara cumplir esta poltica ocultando algunas de las entradas del edificio, ni por la legislacin requirente que requieren el uso de la puerta delantera y prohibiendo que cualquiera pueda revelar el hecho de que hay otras puertas del edificio.

Historia Nadia enva a Dirk el URI del actual artculo que ella Lee. Con su navegador, Dirk sigue el vnculo de hipertexto y se le pide que introduzca su nombre de usuario de suscriptor y contrasea. Ya Dirk es tambin abonados a los servicios prestados por "weather.example.com", puede acceder a la misma informacin que Nadia. Por lo tanto, la autoridad para "weather.example.com" puede limitar el acceso a partes autorizadas y seguir proporcionando los beneficios de URI. El Web proporciona varios mecanismos para controlar el acceso a los recursos; estos mecanismos no dependen de ocultar o suprimir a URIs para esos recursos. Para obtener ms informacin, consulte la etiqueta encontrar "' Deep Linking' la World en Wide Web". 3.5.3. Apoyo de navegacin Es una fuerza de la arquitectura Web que vnculos pueden hecho y compartido; un usuario que ha encontrado una parte interesante de la Web puede compartir esta experiencia slo por volver a publicar un URI.

Historia Nadia y Dirk desean visitar el Museo de pronstico meteorolgico en Oaxaca. Nadia va a "http://maps.example.com", localiza el Museo y el URI "http://maps.example.com/oaxaca?lat=17.065;lon=96.716;scale=6" de mails a Dirk. Dirk va a "http://mymaps.example.com", localiza el Museo y el URI "http://mymaps.example.com/geo?sessionID=765345;userID=Dirk" de mails a Nadia. Dirk lea el correo electrnico de Nadia y es capaz de seguir el enlace al mapa. Nadia lea el correo electrnico de Dirk, sigue el enlace y recibe un mensaje de error "No esa sesin/usuario". Nadia tiene que empezar de nuevo desde "http://mymaps.example.com" y encontrar la ubicacin del Museo una vez ms. Los recursos que se generan en la demanda, generacin de mquina de URI es comn. Para los recursos que podran tilmente ser marcados para la lectura posterior o compartir con otros usuarios, administradores de servidores deben evitar restringir innecesariamente la reutilizacin de dichas URIs. Si se pretende restringir la informacin a un usuario concreto, como podra ser el caso en una casa bancaria aplicacin por ejemplo, los diseadores deben utilizar mecanismos adecuados de control de acceso (3) .

Interacciones con HTTP POST (donde HTTP GET podran haber utilizado) tambin limitan las posibilidades de navegacin. El usuario no puede crear un marcador o compartir el URI porque transacciones HTTP POST no suele resultar en otro URI como el usuario interacta con el sitio.

3.6. Orientaciones futuras de interaccin

Quedan cuestiones pendientes en relacin con las interacciones de la Web. La etiqueta de espera de futuras versiones de este documento para abordar con ms detalle la relacin entre la arquitectura describen, Servicios Web, sistemas peer-topeer, instantneos sistemas de mensajera (como [RFC3920]), secuencias de audio (como RTSP [RFC2326]) y voz sobre IP (como SIP [RFC3261]).

4. Formatos de datos
Un formato de datos de especificacin (por ejemplo, para XHTML, RDF/XML, SMIL, XLink, CSS y PNG) encarna a un acuerdo sobre la correcta interpretacin de los datos de representacin . El primer formato de datos utilizado en la Web fue HTML. Desde entonces, los formatos de datos han crecido en nmero. Arquitectura Web no restringir formatos de datos que pueden utilizar los proveedores de contenido. Esta flexibilidad es importante porque hay constante evolucin en aplicaciones, resultando en nuevos formatos de datos y mejoras de los formatos existentes. Aunque la arquitectura Web permite el despliegue de nuevos formatos de datos, la creacin e implementacin de nuevos formatos (y agentes capaces de manejarlos) es caro. Por lo tanto, antes de inventar un nuevo formato de datos (o formato de "meta" como XML), los diseadores deben considerar cuidadosamente reutilizando uno que ya est disponible. Para que un formato de datos ser til interoperables entre dos partes, las partes deben aceptar (en una medida razonable) sobre su sintaxis y semntica. Visin compartida de un formato de datos promueve la interoperabilidad, pero no implica restricciones en el uso; por ejemplo, un emisor de datos no puede contar con poder restringir el comportamiento de un receptor de datos. A continuacin se describen algunas de las caractersticas de un formato de datos que facilitan la integracin en la arquitectura Web. Este documento no contempla las caractersticas generalmente beneficiosas de una especificacin como la legibilidad, la sencillez, la atencin a los objetivos de programador, atencin a las necesidades del usuario, la accesibilidad, ni la internacionalizacin. La seccin de especificaciones de la arquitectura (7.1) incluye referencias a las directrices de especificacin de formato adicionales.

4.1. Formatos de datos binarios y de texto

Formatos de datos binarios son aquellos en que porciones de los datos se codifican para su uso directo por procesadores de equipos, por ejemplo 32 bits little-endian notacin complementaria y 64 bits IEEE precisin doble punto flotante. Las porciones de datos tan representados son valores numricos, punteros y datos comprimidos de todo tipo. Un formato de datos textuales es uno en que los datos se especifican en una codificacin definida como una secuencia de caracteres. HTML, el correo electrnico de Internet y todos los formatos basados en XML (4.5) son textual. Cada vez ms globalizado datos textuales formatos refieren al repertorio Unicode [UNICODE] para definiciones de carcter. Si hay un formato de datos textual, como se define en esta seccin, que no implica que se sirve con un tipo de medios de comunicacin a partir de "texto /". Aunque los formatos basados en XML son textuales, muchos formatos basados en XML no constan principalmente de frases en lenguaje natural. Consulte la seccin sobre los tipos de medios para XML (4.5.7) para las cuestiones que se plantean cuando "texto /" se utiliza junto con un formato basado en XML. En principio, todos los datos pueden representarse mediante formatos de texto. En la prctica, algunos tipos de contenido (por ejemplo, audio y video) generalmente se representan mediante formatos binarios. Las ventajas y desventajas entre los formatos de datos binarios y de texto son complejas y dependientes de las aplicaciones. Formatos binarios pueden ser sustancialmente ms compactos, especialmente para estructuras de datos complejas de puntero ricos. Adems, puede consumir ms rpidamente por los agentes en los casos en donde pueden ser cargados en la memoria y con poca o ninguna conversin. Nota, sin embargo, que tales casos son relativamente poco frecuente uso directo como tal puede abrir la puerta a las cuestiones de seguridad que prcticamente slo puede abordarse mediante el examen de todos los aspectos de la estructura de datos en detalle. Formatos de texto suelen ser ms porttiles e interoperables. Formatos de texto tambin tienen la ventaja considerable que puede leer directamente por los seres humanos (y entender, dado suficiente documentacin). Esto puede simplificar las tareas de creacin y mantenimiento de software y permite la intervencin directa de los seres humanos en la cadena de procesamiento sin recurrir a herramientas ms complejo que el texto ubicuo editor. Finalmente, simplifica la tarea humana necesaria de conocer datos nuevos formatos; Esto se llama el efecto de "ver cdigo fuente". Es importante destacar intuicin como a cuestiones tales como el tamao de los datos y la velocidad de procesamiento no es una gua confiable en el diseo del formato de datos; estudios cuantitativos son esenciales para una correcta comprensin de las ventajas y desventajas. Por lo tanto, diseadores de una especificacin de formato de datos deben hacer una eleccin considerada entre diseo de formato binario y textual. Consulte la etiqueta nmero binaryXML-30.

4.2. Control de versiones y extensibilidad

En un mundo perfecto, diseadores de idioma seran inventar idiomas que perfectamente se reunieron los requisitos presentados para ellos, los requisitos sera un modelo perfecto del mundo, nunca se cambian con el tiempo y todas las implementaciones sera perfectamente interoperables porque las especificaciones no tendra ninguna variabilidad. En el mundo real, diseadores de lengua imperfecta abordan los requisitos como que interpretan, los requisitos incorrectamente modelar el mundo, se presentan requisitos conflictivos y cambian con el tiempo. Como resultado, diseadores negociacin con los usuarios, hacen concesiones y a menudo introducen mecanismos de extensibilidad para que

sea posible evitar problemas en el corto plazo. A largo plazo, que producen varias versiones de sus lenguas, como el problema y su comprensin de la misma, evolucionan. La variabilidad en especificaciones, idiomas e implementaciones resultante presenta costos de interoperabilidad. Control de versiones y extensibilidad son estrategias para ayudar a administrar la evolucin natural de la informacin en la Web y las tecnologas utilizadas para representar esa informacin. Para obtener ms informacin acerca de cmo introducen estas estrategias variabilidad y cmo esa variabilidad afecta interoperabilidad, consulte variabilidad en especificaciones. Consulte la etiqueta nmero 41 de XMLVersioning, que se refiere a las buenas prcticas para el diseo extensibles lenguajes XML y para el manejo de versiones. Vase tambin "Arquitectura: Extensible lenguajes Web" [EXTLANG]. 4.2.1. Control de versiones Normalmente hay un (largo) perodo de transicin durante el cual varias versiones de un formato, Protocolo o agente simultneamente estn en uso.

Buenas prcticas: informacin sobre la versin DEBE proporcionar una especificacin de formato de datos para obtener informacin de versin.

4.2.2. Poltica de control de versiones y XML namespace

Historia Nadia y Dirk estn diseando un formato de datos XML para codificar datos sobre la industria del cine. Prevn extensibilidad mediante el uso de espacios de nombres XML y crear un esquema que permita la inclusin, en ciertos lugares, de elementos de cualquier espacio. Cuando revisa su formato, Nadia propone un nuevo atributo opcional de lang en el elemento de la film . Dirk siente que ese cambio les obliga a asignar un nuevo nombre de espacio de nombres, que puede requerir modificaciones de software implementado. Nadia explica a Dirk que su eleccin de la estrategia de extensibilidad junto con su poltica de espacio de nombres permite ciertos cambios que no afectan a la conformidad de contenido y software existentes, y por lo tanto no se requiere ningn cambio en el identificador de espacio de nombres. Ellos escogieron esta poltica para ayudarles a cumplir sus metas de reducir el coste del cambio. Dirk y Nadia han elegido un espacio de nombres concreto cambiar poltica que le permita evitar cambiar el nombre de espacio de nombres cuando se hacen cambios que no afectan a la conformidad del software y contenido desplegado. Tal vez han elegido una poltica diferente, por ejemplo que cualquier nuevo elemento o atributo tiene que pertenecer a un espacio de nombres distinto del original. Cualquiera que sea la poltica elegida, deben establecer expectativas claras para los usuarios del formato. En general, cambiar el espacio de nombres de nombre de un elemento cambia completamente el nombre del elemento. Si "a" y "b" est obligado a dos diferentes URIs, a:element y b:element son tan distintos como a:eieio y a:xyzzy. Prcticamente hablando, esto significa que implementa aplicaciones tendrn que actualizarse a fin de reconocer el nuevo idioma; el costo de esta actualizacin puede ser muy alto. Se deduce que hay ventajas y desventajas importantes a tener en cuenta al decidir sobre una poltica de cambio de espacio de nombres. Si no dispone de un vocabulario extensibilidad puntos (es decir, si no permite elementos o atributos de los espacios de nombres extranjeros o disponer de un mecanismo para tratar con nombres no reconocidos en el mismo espacio de nombres), puede que sea absolutamente necesario cambiar el nombre de espacio de nombres. Idiomas que permiten alguna forma de extensibilidad sin necesidad de un cambio en el nombre de espacio de nombres tienen ms probabilidades de desarrollarse correctamente.

Buenas prcticas: poltica de Namespace Una especificacin de formato XML debe incluir informacin sobre las polticas de cambio para espacios de nombres XML. Como un ejemplo de una poltica de cambio diseado para reflejar la estabilidad variable de un espacio de nombres, considerar la poltica de espacio de nombres de W3C para documentos en la pista de la recomendacin del W3C. La poltica establece las expectativas de que el grupo de trabajo responsable del espacio de nombres puede modificarlo de ninguna manera hasta cierto punto en el proceso ("recomendacin de candidato"), en qu punto W3C restringe el conjunto de posibles cambios en el espacio de nombres a fin de promover las implementaciones estables. Tenga en cuenta que ya nombres de espacio de nombres son URI, el dueo de un espacio de nombres URI tiene la autoridad para decidir la poltica de cambio de espacio de nombres. 4.2.3. Extensibilidad Requerimientos cambian con el tiempo. Las tecnologas exitosas son adoptadas y adaptadas por nuevos usuarios. Los diseadores pueden facilitar el proceso de transicin decisiones cuidadoso acerca de extensibilidad durante el diseo de una especificacin de lenguaje o Protocolo.

En estas decisiones, los diseadores deben sopesar las ventajas y desventajas entre la extensibilidad, la simplicidad y la variabilidad. Un lenguaje sin mecanismos de extensibilidad puede ser ms simple y menos variable, mejorar la interoperabilidad inicial. Sin embargo, es probable que los cambios a ese idioma ser ms difciles, posiblemente ms complejo y ms variable, que si el diseo inicial haba proporcionado esos mecanismos. Esto puede reducir la interoperabilidad en el largo plazo.

Buenas prcticas: mecanismos de extensibilidad Una especificacin debe proporcionar mecanismos que permiten a cualquier parte crear extensiones. Extensibilidad presenta la variabilidad que tiene un impacto sobre interoperabilidad. Sin embargo, idiomas que no tienen ningn mecanismo de extensibilidad podrn ampliarse de manera ad hoc as la interoperabilidad de impacto. Un criterio clave de los mecanismos previstos por los diseadores del lenguaje es que permiten las lenguas extendidas a permanecer en conformidad con la especificacin original, aumentando la probabilidad de interoperabilidad.

Buenas prcticas: cumplimiento de extensibilidad Extensibilidad no debe interferir en conformidad con la especificacin original. Aplicacin necesita determinar la estrategia de extensin ms apropiada para una especificacin. Por ejemplo, las aplicaciones diseadas para operar en entornos cerrados pueden permitir a los diseadores de especificacin definir una estrategia de control de versiones que sera poco prctica en la escala de la Web.

Buenas prcticas: extensiones desconocidas Una especificacin debe especificar el comportamiento de agente ante las extensiones no reconocidas. Han surgido dos estrategias, siendo particularmente til: 1. "Debe ignorar": el agente omite cualquier contenido que no reconoce. 2. "Debe entender": el agente trata de formato no reconocido como una condicin de error. Es un enfoque de diseo poderoso para que el idioma para permitir que cualquier forma de extensin, pero distinguir explcitamente entre ellos en la sintaxis. Estrategias adicionales incluyen pedir al usuario ms entrada y recuperar automticamente datos de vnculos de hipertexto disponible. Tambin son posibles, incluida la mezcla estrategias estrategias ms complejas. Por ejemplo, un lenguaje puede incluir mecanismos para anular el comportamiento estndar. As, un formato de datos puede especificar "debe ignorar" semntica pero tambin permiten extensiones que anulacin esa semntica a la luz de las necesidades de la aplicacin (por ejemplo, con "debe entender" semntica para una extensin determinada). Extensibilidad no es libre. Proporcionar ganchos para extensibilidad es uno de muchos requisitos para ser incluido en los costos de diseo del lenguaje. La experiencia sugiere que los beneficios a largo plazo de un mecanismo de extensibilidad bien diseados por lo general superan los costos. Consulte "extensiones y extensibilidad D.3" en [QA]. 4.2.4. Composicin de los formatos de datos Formato de datos modernas muchos incluyen mecanismos de composicin. Por ejemplo: Es posible incrustar comentarios de texto en algunos formatos de imagen, como JPEG/JFIF. Aunque estos comentarios estn incrustados en los datos que contiene, no estn diseados para afectar a la visualizacin de la imagen. Hay formatos contenedores como el jabn que esperan plenamente el contenido de varios espacios de nombres pero que proporcionen una relacin semntica general de mensaje envolvente y carga. La semntica de la combinacin de documentos RDF que contiene varios vocabularios est bien definida. En principio, estas relaciones pueden ser mezcladas y anidadas arbitrariamente. Un mensaje SOAP, por ejemplo, puede contener una imagen SVG que contiene un comentario de RDF que se refiere a un vocabulario de trminos para describir la imagen. Sin embargo, nota que para XML general no existe ningn modelo semntico que define las interacciones dentro de documentos XML con elementos o atributos de una variedad de espacios de nombres. Cada aplicacin debe definir cmo interactan los espacios de nombres y qu efecto el espacio de nombres de elemento tiene antepasados, hermanos y descendientes del elemento. Consulte la etiqueta cuestiones mixedUIXMLNamespace-33 (relacin con el significado de un documento compuesto de contenido en varios espacios de nombres), xmlFunctions-34 (sobre un enfoque para la administracin de composability y la transformacin de XML) y RDFinXHTML-35 (relativa a la interpretacin de RDF cuando incrustado en un documento XHTML).

4.3. Separacin del contenido, la presentacin y la interaccin

La Web es un entorno heterogneo donde una amplia variedad de agentes proporcionar acceso al contenido a los usuarios con una amplia variedad de capacidades. Es una buena prctica para los autores crear contenido que puede alcanzar la mayor audiencia posible, incluidos los usuarios de computadoras de escritorio grficas, dispositivos porttiles y telfonos mviles, los usuarios con discapacidades que necesitan dispositivos an no se han imaginado y sintetizadores de voz. Adems, los autores no pueden predecir en algunos casos cmo un agente ser mostrar o procesar su contenido. La experiencia demuestra que la separacin del contenido, la presentacin y la interaccin promueve la reutilizacin y la independencia de dispositivos de contenido; Esto se desprende el principio de especificaciones ortogonales (5.1). Esta separacin tambin facilita la reutilizacin de contenido de origen creados en mltiples contextos de entrega. A veces, experiencias de usuario funcional adecuados para cualquier contexto de entrega pueden generarse mediante un proceso de adaptacin aplicado a una representacin que no dependen del mecanismo de acceso. Para obtener ms informacin sobre los principios de independencia de dispositivos, consulte [DIPRINCIPLES].

Buenas prcticas: separacin de contenido, presentacin, interaccin Una especificacin debe permitir autores separar contenido de presentacin y la interaccin de preocupaciones. Observe que al contenido, la presentacin y la interaccin estn separados por diseo, agentes necesitan recombinarles. En un extremo hay un espectro de recombinacin con "cliente hace todo" y "servidor hace todo" en el otro. Hay ventajas en cada enfoque. Por ejemplo, cuando un cliente (como un telfono mvil) comunica las capacidades del dispositivo al servidor (por ejemplo, mediante CC/PP), el servidor puede adaptar el contenido entregado para adaptarse a ese cliente. El servidor puede, por ejemplo, habilitar descargas ms rpidas ajustando enlaces para hacer referencia a imgenes bajas resolucin, video ms pequeo o ningn vdeo a todos. Del mismo modo, si el contenido ha sido creado con varias ramas, el servidor puede quitar ramas no utilizadas antes de la entrega. Adems, adaptando el contenido que coincide con las caractersticas de un cliente de destino, el servidor puede ayudar a reducir clculo de lado del cliente. Sin embargo, contenido especializado de esta manera reduce la eficiencia de almacenamiento en cach. Por otro lado, el diseo de contenido que puede ser recombinado en el cliente tambin tiende a hacer que el contenido aplicable a una amplia gama de dispositivos. Este diseo tambin mejora la eficiencia del almacenamiento en cach y ofrece a los usuarios ms opciones de presentacin. Hojas de estilos dependientes de los medios de comunicacin pueden utilizarse para adaptar el contenido del lado cliente para determinados grupos de dispositivos de destino. Para el contenido textual con una estructura regular y repetida, el tamao combinado de los contenidos de texto ms la hoja de estilos es normalmente menor que el de contenido totalmente recombinada; el ahorro de mejora an ms si se reutiliza la hoja de estilos por otras pginas. En la prctica se utiliza a menudo una combinacin de ambos enfoques. La decisin de diseo acerca de dnde en este espectro que debe colocarse una aplicacin depende de la potencia en el cliente, el poder y la carga en el servidor y el ancho de banda del medio que los conecta. Si el nmero de posibles clientes es ilimitado, la aplicacin escalar mejor si el cmputo ms se enva al cliente. Por supuesto, no puede ser conveniente para llegar a la mayor audiencia posible. Los diseadores deben considerar las tecnologas apropiadas, tales como la encriptacin y control de acceso (3), para limitar la audiencia. Algunos formatos de datos estn diseados para describir la presentacin (incluyendo SVG y XSL Formatting Objects). Formatos de datos como estos demuestran que uno slo puede separar contenido de presentacin (o interaccin) hasta la fecha; en algn momento se hace necesario hablar de presentacin. Por el principio de especificaciones ortogonales (5.1) de estos formatos de datos deben enfrentar solo los problemas de presentacin. Consulte la etiqueta cuestiones formattingProperties-19 (relativa a la interoperabilidad en el caso de nombres y propiedades de formato) y contentPresentation-26 (relativas a la separacin de marcado semntico y presentacin).

4.4. Hipertexto
Una caracterstica definitoria de la Web es que permite incrustadas referencias a otros recursos a travs de URI. La simplicidad de la creacin de vnculos de hipertexto utilizando identificadores URI absolutos (<a href="http://www.example.com/foo">) y referencias URI relativas (<a href="foo"> y <a href="foo#anchor">) es en parte (quizs) responsable en gran parte el xito del hipertexto Web tal como la conocemos hoy. Cuando una representacin de un recurso contiene una referencia a otro recurso, expresado con un URI identifica que otros recursos, esto constituye un vnculo entre los dos recursos. Metadatos adicionales tambin pueden formar parte del enlace (vase [XLink10], por ejemplo). Nota: En este documento, el trmino "enlace" generalmente significa "relacin", no "conexin fsica".

Buenas prcticas: identificacin de enlace Una especificacin debe proporcionar formas de identificar vnculos a otros recursos, incluyendo a recursos secundarios (a travs de identificadores de fragmento). Formatos que permiten a los autores de contenido utilizar URIs en lugar de identificadores locales promocin el efecto de red: el valor de estos formatos crece con el tamao de la Web implementado.

Buenas prcticas: enlace Web

Una especificacin debe permitir vincular, documento interno no slo une toda la Web.

Buenas prcticas: URI genrico Una especificacin debe permitir autores de contenido utilizar a URIs sin restriccin de un conjunto limitado de esquemas de URI. Qu agentes con un vnculo de hipertexto no est limitado por la arquitectura Web y puede depender de contexto de aplicacin. Los usuarios de vnculos de hipertexto esperan poder navegar entre representaciones siguiendo los vnculos.

Buenas prcticas: vnculos de hipertexto Un formato de datos debe incorporar vnculos de hipertexto si hipertexto es el paradigma de la interfaz de usuario esperados. Formatos de datos que no permita que los autores de contenido crear vnculos de hipertexto conducen a la creacin de "nodos terminales" en la Web. 4.4.1. Referencias URI Enlaces comnmente se expresan mediante referencias URI (definida en el punto 4.2 de [URI]), que pueden combinarse con un URI base para producir un URI utilizable. Seccin 5.1 de [URI] explica diferentes maneras de establecer un URI base para un recurso y establece una prioridad entre ellos. Por ejemplo, el identificador URI base puede ser un URI del recurso o especificado en una representacin (vase los elementos base proporcionados por el encabezado HTTP 'Content-Location', HTML y XML). Vase tambin la seccin sobre vnculos de XML (4.5.2). Agentes resolver una referencia de identificador URI antes de utilizar el identificador URI resultante para interactuar con otro agente. URI referencias ayuda en administracin de contenido al permitir que los autores de contenido para el diseo de una representacin local, es decir, sin preocupacin cuyo identificador global puede utilizarse posteriormente para referirse a los recursos asociados.

4.5. Formatos de datos basados en XML

Muchos formatos de datos basados en XML, es decir se ajusten a las reglas de sintaxis definidas en la especificacin de XML [XML10] o [XML11]. Esta seccin describe los problemas especficos de esos formatos. Cualquiera que busque orientacin en esta rea se insta a consultar las "Directrices para el uso de XML en protocolos del IETF" [IETFXML], que contiene una discusin detallada de las consideraciones que rigen o no debe utilizar XML, as como directrices especficas sobre cmo deben utilizar. Mientras se dirige a las aplicaciones de Internet con referencia especfica a los protocolos, la discusin es generalmente aplicable a escenarios de Web as. El debate debe considerarse como auxiliares en el contenido de [IETFXML]. Consulte tambin "Pautas de accesibilidad de XML" [XAG] ayuda a disear formatos XML que reduccin las barreras a la accesibilidad Web para personas con discapacidades. 4.5.1. Cundo se debe utilizar un formato basado en XML XML define formatos de datos textual que naturalmente se ajustan a la descripcin de los objetos de datos jerrquica y transformados en una secuencia elegida. Es ampliamente, pero no universalmente aplicable para los formatos de datos; un formato de audio o vdeo, por ejemplo, es poco probable que sea adecuado para la expresin en XML. Las restricciones de diseo que sugieren el uso de XML incluyen: 1. 2. 3. 4. 5. 6. 7. 8. 9. Requisito de una estructura jerrquica. Necesidad de una amplia gama de herramientas en una variedad de plataformas. Necesidad de datos que pueden sobrevive a las aplicaciones que actualmente procesan. Capacidad para apoyar la internacionalizacin de una manera autodescriptivo que hace la confusin sobre la codificacin opciones poco probable. Deteccin temprana de errores sin necesidad de "evitar" este tipo de errores de codificacin. Una alta proporcin de contenido textual legible. Composicin potencial del formato de datos con otros formatos XML codificado. Deseo de datos fcilmente analizados por los seres humanos y mquinas. Deseo de vocabularios que puede ser inventado en forma distribuida y combinado con flexibilidad.

4.5.2. Enlaces en XML Se han inventado sofisticados mecanismos de vinculacin para formatos XML. XPointer permite enlaces a contenido de direccin que no tienen un explcito, anclaje con nombre. [XLink] es una especificacin adecuada para representar vnculos de hipertexto (4.4) aplicaciones de XML. XLink permite enlaces tienen varios extremos y que expresaron ya sea en lnea o "vincular bases" almacenados externos para cualquiera o todos los recursos identificados por los vnculos que contiene. Consideren diseadores de formatos basados en XML utilizando XLink y, para la definicin de sintaxis de identificador de fragmento, utilizando el marco del XPointer y XPointer element() esquemas.

XLink no es el nico diseo vinculacin que ha sido propuesto para XML, ni es universalmente aceptado como un bu en diseo. Vase tambin TAG cu estin xlinkScope-23. 4.5.3. Espacios de nombres XML El propsito de u espacio de nombres XML (definido en [XMLNS]) es para permitir el despliegue de vocabu n larios XML (en qu elementos y atributos se definen los nombres) en un entorno global y para reducir el riesgo de conflictos de nombres en un documento dado cu ando se combinan los vocabu larios. Por ejemplo, las especificaciones MathML y SVG definen el elemento set . Aunque los datos XML de diferentes formatos como MathML y SVG pu eden combinarse en u nico n docu mento, en este caso podra ser ambigedad acerca de que pretenda set el elemento. Espacios de nombres XML redu cen el riesgo de conflictos de nombres por tomar ventaja de los sistemas existentes para asignar globalmente con mbito de nombres: el sistema URI (vase tambin la seccin sobre la asignacin de URI (2.2.2)). Al utilizar espacios de nombres XML, cada nombre local en u vocabulario XML est emparejado con u URI (llamado el URI de espacio de nombres) para n n distinguir el nombre local de nombres locales en otros vocabu larios. El uso de URI confiere beneficios adicionales. En primer lu gar, cada par de nombre URI/local se puede asignar a otro URI, los trminos del vocabulario de toma de tierra en la Web. Estas condiciones pueden ser importantes recu rsos y por lo tanto es adecuado poder asociar a URIs con ellos. [RDFXML] u tiliza simple concatenacin de los URI de espacio de nombres y el nombre local para crear un URI para el trmino identificado. Otras asignaciones estn probables que sean ms adecuados para espacios de nombres jerrquico; vase la relacionadas TAG cu estin abstractComponentRefs-37. Diseadores de formatos de datos basados en XML que declaran espacios de nombres hacen as posible reutilizar esos formatos de datos y combinarlos en novedosa an no imaginaba. No declarar espacios de nombres hace dicha reutilizacin ms difcil, incluso imposible en algu nos casos.

Buenas prcticas: adopcin de Namespace Una especificacin que establece u vocabulario XML debe colocar todos los nombres de elemento y atribu n to global en un espacio de nombres. Atributos siempre son el mbito por el elemento en el qu aparecen. Un atributo que es "global", es decir, uno que puedan e aparecer significativamente sobre los elementos de muchos tipos, incluyendo elementos en otros espacios de nombres, debe colocar explcitamente en u espacio de nombres. Atribu locales, los asociados con slo un tipo de elemento en particular, n tos no deben inclu irse en u espacio de nombres ya qu su significado siempre ser claro desde el contexto proporcionado por n e ese elemento. El atribu de type del espacio de nombres de instancia de esquema XML W3C "http://www.w3.org/2001/XMLSchemato n ede u tilizarse por au tores de cualquier instance" ([XMLSCHEMA], seccin 4.3.2) es un ejemplo de u atributo global. Pu vocabulario para hacer u afirmacin en datos de instancia sobre el tipo de elemento en el que aparece. Como un atributo na global, se debe siempre ser clasificado. El atributo de frame en u tabla HTML es u ejemplo de un atributo local. No hay na n ningn valor en la colocacin de ese atributo en un espacio de nombres ya qu el atributo es poco probable qu sea til en un e e elemento distinto de una tabla HTML. Las aplicaciones que se basan en DTD procesamiento deben imponer restricciones adicionales sobre el uso de los espacios de nombres. DTD realizan validacin basada en la forma lxica de los nombres de elementos y atributos en el docu mento. Esto hace prefijos sintcticamente significativo de maneras que no son anticipadas por [XMLNS]. 4.5.4. Documentos Namespace

Historia Nadia recibe datos de la representacin de "weather.example.com" en un formato de datos desconocidos. Ella sabe lo suficiente acerca de XML para reconocer que los elementos pertenecen a espacio de nombres XML. Desde el espacio de nombres es identificado por el URI "http://weather.example.com/2003/format", ella le pide su navegador para recuperar una representacin del recu identificado. Ella vuelve algunos datos tiles que permite obtener rso ms informacin sobre el formato de datos. Explorador de Nadia tambin puede realizar algu nas operaciones automticamente (es decir, desatendida por un su pervisor humana) dado datos que han sido optimizados para agentes de software. Por ejemplo, su navegador podra, en nombre de Nadia, Descargar agentes adicionales para procesar y representar el formato. Otra ventaja de u tilizar URIs para constru espacios de nombres XML es que el URI de espacio de nombres pu ir ede u tilizarse para identificar un recu de informacin que contiene informacin til, mquina utilizable y humanos utilizable, sobre las rso condiciones en el espacio de nombres. Este tipo de recu rsos de informacin se denomina un documento de espacio de nombres. Cuando un propietario URI de espacio de nombres proporciona u docu n mento de espacio de nombres, est autorizado para el espacio de nombres. Hay muchas razones para proporcionar un documento de espacio de nombres. Una persona que desee: entender el propsito del espacio de nombres, Aprenda a utilizar el vocabu lario de la marca en el espacio de nombres Averige qu controla las polticas asociadas y in solicitar autoridad para esquemas de acceso o material publicitario, o informar de un error o u situacin que podra considerarse un error en algn material publicitario. na

Un procesador que desee: recuperar un esquema de validacin, recuperar una hoja de estilo, presentacin, o recuperar ontologas para hacer inferencias. En general, no existe ninguna prctica mejor establecida para crear representaciones de un documento de espacio de nombres; las expectativas de la aplicacin influir en qu formato de datos o formatos que se utilizan. Expectativas de aplicacin influir tambin informacin relevante aparece directamente en una representacin o se hace referencia de ella.

Buenas prcticas: Namespace documentos El propietario de un nombre de espacio de nombres XML debe hacer disponible material destinado a las personas a leer y material optimizado para agentes de software a fin de satisfacer las necesidades de aquellos que utilizar el vocabulario de espacio de nombres. Por ejemplo, los siguientes son ejemplos de formatos de datos de documentos de espacio de nombres: [OWL10], [RDDL], [XMLSCHEMA] y [XHTML11]. Cada uno de estos formatos rene diferentes requisitos descritos anteriormente para satisfacer las necesidades de un agente que quiere ms informacin sobre el espacio de nombres. Nota, sin embargo, cuestiones relacionadas con los identificadores de fragmento y negociacin de contenido (3.2.2) si se usa negociacin de contenido. Consulte la etiqueta cuestiones namespaceDocument-8 (sobre las caractersticas deseadas de documentos de espacio de nombres) y abstractComponentRefs-37 (relativa al uso de identificadores de fragmento con nombres de espacio de nombres para identificar componentes abstractos). 4.5.5. QNames en XML 3 De la seccin de "Namespaces in XML" [XMLNS] proporciona una construccin sintctica conocida como un QName para la expresin compacto de nombres completos en documentos XML. Un nombre completo es un par formado por un identificador URI, que nombra a un espacio de nombres, y un nombre local coloca dentro de ese espacio de nombres. "Namespaces in XML" prev el empleo de QNames como nombres de elementos y atributos XML. Otras especificaciones, comenzando con [XSLT10], han empleado la idea de usar QNames en contextos distintos de los nombres de elemento y atributo, por ejemplo en valores de atributos y contenido del elemento. Sin embargo, los procesadores XML generales no confiable reconocen QNames como tal cuando se utilizan en los valores de atributos y contenido del elemento; por ejemplo, la sintaxis de QNames se superpone con la de URI. Experiencia ha puesto de manifiesto tambin otras limitaciones a QNames, tales como prdida de vinculaciones de espacio de nombres despus de la canonizacin de XML.

Restriccin: QNames indistinguibles de URI No permitir URI y QNames en los valores de atributo o el contenido del elemento donde son indistinguibles. Para obtener ms informacin, consulte la etiqueta encontrar "QNames utilizando como identificadores de contenido". Porque QNames son compactos, algunos diseadores de especificacin han adoptado la misma sintaxis como un medio de identificacin de recursos. Aunque es conveniente como una notacin abreviada, este uso tiene un costo. Hay absoluto nica y aceptado para convertir un QName en un URI o viceversa. Aunque QNames son convenientes, no reemplazan la URI como el sistema de identificacin de la Web. El uso de QNames para identificar recursos Web sin proporcionar una asignacin a URI es incompatible con la arquitectura Web.

Buenas prcticas: QName Mapping Una especificacin que QNames servir como identificadores de recursos deben proporcionar una asignacin a URIs. Ver espacios de nombres XML (4.5.3) para ver ejemplos de algunas estrategias de asignacin. Vase tambin TAG emite rdfmsQnameUriMapping 6 (relativo a la asignacin de QNames a URIs), qnameAsId-18 (sobre el uso de QNames como identificadores de contenido XML) y abstractComponentRefs-37 (relativa al uso de identificadores de fragmento con nombres de espacio de nombres para identificar componentes abstractos). 4.5.6. Semntica de ID XML Considere el siguiente fragmento de XML: <section name="foo">. Tiene el elemento de section lo que la recomendacin XML se refiere a que la ID foo (por ejemplo, "foo" debe no aparecen en el documento XML circundante ms de una vez)? Uno no puede responder a esta pregunta examinando el elemento y sus atributos por s sola. En XML, la calidad de "ser un ID" est asociado con el tipo de un atributo, no su nombre. Encontrar el ID de un documento requiere procesamiento adicional. 1. Procesamiento del documento con un procesador que reconoce las declaraciones de lista de atributos DTD (en el subconjunto interno o externo) podra revelar una declaracin que identifica el name de atributo como un ID. Nota: Este

proceso no es necesariamente parte de validacin. Una no validar, consciente de la DTD procesador puede reconocer IDs. 2. El documento con un esquema XML W3C de procesamiento podra revelar una declaracin de elemento que identifica el name de atributo como un esquema XML de W3C ID. 3. En la prctica, el procesamiento del documento con otro lenguaje de esquema, como RELAX NG [RELAXNG], podra revelar los atributos declarados de ID en el sentido de esquema XML. Muchas especificaciones modernas empiezan a procesar XML Infoset [INFOSET] nivel y no especifica normativamente cmo se construye un Infoset. Para dichas especificaciones, cualquier proceso que establece el tipo de ID en el Infoset (y Post Infoset de validacin de esquema (muy) definido en [XMLSCHEMA]) til puede identificar los atributos de tipo ID. 4. En la prctica, las aplicaciones pueden tener medios independientes (como los definidos en la especificacin del XPointer, [XPTRFR] punto 3.2) de localizar identificadores dentro de un documento. Para complicar an ms las cosas, DTD establecen el tipo de ID en Infoset Considerando que W3C XML Schema produce un muy pero no modifica el Infoset original. Esto deja abierta la posibilidad de que un procesador slo podra ser en el conjunto de informacin y en consecuencia sera dejar de reconocer el esquema asignado IDs. Consulte la etiqueta cuestin 32 xmlIDSemantics para obtener informacin general adicional y [XML ID] para una solucin de bajo desarrollo. 4.5.7. Tipos de medios para XML RFC 3023 define la Internet medios tipos "application/xml" y "text/xml" y describe un Convenio mediante el cual los formatos de datos basados en XML utilizan tipos de medios de Internet con un "+ xml" sufijo, por ejemplo "imagen/svg + xml". Hay dos problemas asociados con los tipos de medios de comunicacin de "texto": primero, para datos identificados como "texto / *", intermediarios de Web pueden "pasar", es decir, convertir la codificacin de caracteres uno a otro. Transcodificacin puede hacer la autodescripcin falsas o puede causar el documento que no es correcto.

Buenas prcticas: XML y "texto / *" En general, un proveedor de representacin no debe asignar tipos de medios de Internet a partir de "texto /" representaciones de XML. Segunda, representaciones cuyos tipos de medios de comunicacin de Internet comienzan con "texto /" son necesarios, salvo que se especifique el parmetro charset , a considerarse a cifrarse en US-ASCII. Dado que la sintaxis de XML est diseada para hacer documentos autodescriptivas, es una buena prctica que omite el parmetro charset , y desde XML muy a menudo no est codificado en US-ASCII, el uso de "texto /" tipos de medios de Internet impide efectivamente esta buena prctica.

Buenas prcticas: XML y codificaciones de caracteres En general, un proveedor de representacin no debe especificar la codificacin de caracteres de datos XML en los encabezados de protocolo ya que los datos son autodescriptivos.

4.5.8. Identificadores de fragmento XML La seccin sobre los tipos de medios de comunicacin y semntica de identificador de fragmento (3.2.1) explica la interpretacin de los identificadores de fragmento. Diseadores de una especificacin de formato de datos basados en XML deben definir la semntica de identificadores de fragmento en ese formato. El marco del XPointer [XPTRFR] proporciona un punto de partida interoperable. Cuando el tipo de medios asignado a los datos de representacin es "application/xml", no hay ningn semntica definida para los identificadores de fragmento y autores no deben hacer uso de identificadores de fragmento en dichos datos. Lo mismo ocurre si el tipo de medios asignados el sufijo "+ xml" (definida en "Tipos de medios de XML" [RFC3023]), y la especificacin de formato de datos especifica semntica de identificador de fragmento. En definitiva, slo saber que el contenido es que XML no proporcionan informacin sobre semntica de identificador de fragmento. Muchas personas asumen que el fragmento identificador #abc, al hacer referencia a datos XML, identifica el elemento en el documento con el ID "abc". Sin embargo, no hay ningn apoyo normativo para esta hiptesis. Se espera que una revisin de RFC 3023 enfrentar esto. Consulte la etiqueta nmero fragmentInXML-28.

4.6. Orientaciones futuras de formatos de datos

Formatos de datos permiten la creacin de nuevas aplicaciones para hacer uso de la infraestructura de informacin espacial. La Web semntica es una dicha aplicacin, construida sobre RDF [RDFXML]. Este documento no trata la Web semntica en detalle; la etiqueta espera que sern futuros volmenes de este documento. Consulte el relacionadas TAG cuestin httpRange-14.

5. Principios de arquitectura general

Una serie de principios de la arquitectura general aplicable a todas las tres bases de la arquitectura Web.

5.1. Especificaciones ortogonales

Identificacin, interaccin y representacin son ortogonales conceptos, lo que significa que las tecnologas utilizadas para la identificacin, la interaccin y la representacin pueden evolucionar de forma independiente. Por ejemplo: Los recursos se identifican con URIs. URI pueden publicarse sin construir ninguna representacin del recurso o determinar si cualquier representaciones estn disponibles. Una sintaxis URI genrica permite que los agentes funcionar en muchos casos sin saber detalles de esquemas de URI. En muchos casos uno puede cambiar la representacin de un recurso sin interrumpir las referencias a los recursos (por ejemplo, mediante negociacin de contenido). Cuando dos especificaciones son ortogonales, uno puede cambiar sin necesidad de realizar cambios al otro, incluso si uno tiene dependencias en el otro. Por ejemplo, aunque la especificacin HTTP depende de la especificacin de URI, los dos pueden evolucionar independientemente. Esta ortogonalidad aumenta la flexibilidad y la solidez de la Web. Por ejemplo, uno puede referirse por URI a una imagen sin saber nada sobre el formato elegido para representar la imagen. Esto ha facilitado la introduccin de los formatos de imagen como PNG y SVG sin interrumpir las referencias existentes a los recursos de la imagen.

Principio: ortogonalidad Abstracciones ortogonales se benefician de especificaciones ortogonales. La experiencia demuestra que surgen problemas donde conceptos ortogonales se producen en una especificacin nica. Consideremos, por ejemplo, la especificacin HTML que incluye la especificacin de x-www-form-urlencoded ortogonal. Los desarrolladores de software (por ejemplo, de aplicaciones [CGI]) podran tener un tiempo ms fcil encontrar la especificacin si fuera publicado por separado y, a continuacin, citado por las especificaciones de HTTP, URI y HTML. Tambin surgen problemas cuando las especificaciones intentan modificar ortogonales abstracciones descritas en otros lugares. Una versin histrica de la especificacin HTML agrega un valor de "Refresh" al atributo del elemento meta httpequiv . Se ha definido como equivalente a la cabecera HTTP del mismo nombre. Los autores de la especificacin de HTTP al final decidieron no proporcionan este encabezado y que hicieron las dos especificaciones torpemente en desacuerdo con ellos. El grupo de trabajo de HTML de W3C finalmente eliminado el valor de "Refresh". Una especificacin debe indicar claramente las funciones que se superponen con los gobernados por otra especificacin.

5.2. Extensibilidad
La informacin en la Web y las tecnologas utilizadas para representar ese cambio de informacin con el tiempo. Extensibilidad es propiedad de una tecnologa que promueve la evolucin sin sacrificar la interoperabilidad. Algunos ejemplos de las tecnologas exitosas diseadas para permitir el cambio mientras minimiza la interrupcin: el hecho de que ortogonalmente se especifican los esquemas de URI; el uso de un conjunto abierto de tipos de medios de Internet en el correo y HTTP para especificar la interpretacin del documento; la separacin de la gramtica XML genrica y el conjunto abierto de espacios de nombres XML para los nombres de elemento y atributo; modelos de extensibilidad en hojas de estilo en cascada (CSS), XSLT 1.0 y jabn; usuario agente plug-ins. Un ejemplo de un mecanismo de extensin es obligatorias extensiones HTTP [HTTPEXT]. La Comunidad ha buscado mecanismos para ampliar HTTP, pero al parecer los costos de la propuesta de extensin obligatoria (en particular en complejidad) superan los beneficios y obstaculizan por tanto aprobacin. A continuacin analizaremos la propiedad de "extensibilidad," exhibida por URI, algunos formatos de datos y algunos protocolos (a travs de la incorporacin de nuevos mensajes). Idioma subconjunto: una lengua es un subconjunto (o "perfil") de un segundo idioma si cualquier documento en la primera lengua es tambin un documento vlido en el segundo idioma y tiene la misma interpretacin en el segundo idioma. Idioma extendido: si una lengua es un subconjunto del otro, el superconjunto de este ltimo se llama lengua extendida; la diferencia entre las lenguas se llama la extensin. Claramente, extendiendo una lengua es mejor para la interoperabilidad que creando un lenguaje incompatible. Idealmente, muchos casos de una lengua superconjunto pueden segura y til procesar como si fueran en el lenguaje de subconjunto. Idiomas que pueden evolucionar de esta forma, permitiendo que las aplicaciones proporcionar nueva informacin cuando sea necesario, mientras todava interoperar con aplicaciones que slo entienden un subconjunto del lenguaje actual, se dicen que son "extensible". Diseadores de lenguaje pueden facilitar la extensibilidad definiendo el comportamiento predeterminado de extensiones desconocidas por ejemplo, que sean ignorados (de alguna manera definida) o debe considerarse errores. Por ejemplo, desde temprano en la Web, HTML agentes siguieron la Convencin de ignorar etiquetas desconocidos. Esta eleccin dej espacio para la innovacin (es decir, los elementos no estndares) y alent a la implementacin de HTML. Sin embargo, tambin surgieron problemas de interoperabilidad. En este tipo de entorno, hay una tensin inevitable entre el deseo de extensibilidad e interoperabilidad en el corto plazo. La experiencia demuestra que diseos que el equilibrio correcto entre permitiendo el cambio y la conservacin de interoperabilidad tienen ms probabilidades de prosperar y son menos propensos a perturbar la comunidad Web. Especificaciones ortogonales (5.1) ayuda a reducir el riesgo de interrupcin.

Para ms informacin, consulte la seccin sobre control de versiones y extensibilidad (4). Vase tambin TAG cuestin xmlProfiles-29 y dialectos HTML.

5.3. Gestin de errores

Se producen errores en los sistemas de informacin en red. Una condicin de error puede ser caracterizada (por ejemplo, bien sean errores en XML o 4xx errores de cliente HTTP) o surgir de forma impredecible. Correccin de error significa que un agente repara una condicin para que dentro del sistema, es como si nunca se ha producido el error. Un ejemplo de correccin de errores implica la retransmisin de datos en respuesta a un error de red temporal. Recuperacin de error significa que un agente no repara una condicin de error, pero contina el procesamiento al enfrentar el hecho de que se ha producido el error. Agentes frecuentemente corregir errores sin conciencia de usuario, spare usuarios los detalles de las comunicaciones de red compleja. Por otro lado, es importante que agentes recuperarse del error de una manera que es evidente para los usuarios, ya que los agentes actan en su nombre.

Principio: recuperacin de errores Agentes que recuperacin del error haciendo una eleccin sin el consentimiento del usuario no estn actuando en nombre del usuario. Un agente no est obligado a interrumpir el usuario (por ejemplo, por reventar un cuadro de confirmacin) para obtener consentimiento. El usuario puede indicar consentimiento a travs de opciones de configuracin preseleccionadas, modos o alterna de interfaz de usuario seleccionables, con la correspondiente notificacin al usuario cuando el agente detecta un error. Los desarrolladores de agente no deben ignorar los problemas de usabilidad al disear el comportamiento de recuperacin de errores. Para promover la interoperabilidad, diseadores de especificacin deben identificar las condiciones de error predecible. Experiencia ha llevado a las siguientes observaciones sobre enfoques de gestin de errores. Diseadores de Protocolo deben proporcionar suficiente informacin acerca de una condicin de error para que un agente puede enfrentar la condicin de error. Por ejemplo, un cdigo de estado HTTP 404 (no encontrado) es til porque permite que los agentes de usuario presentar la informacin pertinente a los usuarios, lo que les permite ponerse en contacto con el proveedor de representacin en caso de problemas. La experiencia con el costo de la construccin de un agente de usuario para manejar las diversas formas de contenido HTML mal formada convencidas a los diseadores de la especificacin de XML para requerir que los agentes no a encontrar mal formaron contenidos. Porque los usuarios estn poco probable que tolerar esos errores, esta opcin de diseo ha presionado a todas las partes a respetar las restricciones de XML, para beneficio de todos. Un agente que se encuentra con contenido desconocido puede manejarlo en varias formas, incluyendo por considerarlo un error; Vase tambin la seccin sobre extensibilidad y control de versiones (4). Comportamiento de error que corresponda a una persona no puede ser apropiado para el software. Las personas son capaces de ejercer el juicio de manera que las aplicaciones de software generalmente no pueden. Una respuesta de error informal puede ser suficiente para una persona pero no para un procesador. Consulte la etiqueta cuestin contentTypeOverride-24, que se refiere a la fuente de metadatos autorizada.

5.4. Basado en el Protocolo de interoperabilidad

La Web sigue la tradicin de Internet en que se definen sus interfaces importantes en trminos de protocolos, especificando la sintaxis, semntica, y secuenciar las limitaciones de los mensajes intercambiados. Protocolos diseados para ser resistente ante la gran diversidad de entornos han ayudado a la Web escalar y han facilitado la comunicacin a travs de varios lmites de confianza. Interfaces de programacin de aplicaciones tradicionales (APIs) no siempre considerar estas restricciones, ni debe ser necesarios. Uno de los efectos de diseo basado en el protocolo es que la tecnologa haba compartida entre los agentes a menudo dura ms tiempo que los propios agentes. Es comn para programadores que trabajan con la Web para escribir cdigo que genera y analiza estos mensajes directamente. Es menos comn, pero no era raro, para que los usuarios finales tienen exposicin directa a estos mensajes. A menudo es conveniente proporcionar a los usuarios con acceso a detalles de formato y Protocolo: lo que les permite "ver cdigo fuente", mediante el cual pueden ganar experiencia en el funcionamiento del sistema subyacente.

6. Glosario
Negociacin de contenido La prctica de proporcionar mltiples representaciones disponibles a travs de la misma direccin URI. Sirve que la representacin depende de la negociacin entre el agente requirente y el agente al servicio de las representaciones. Eliminar la referencia URI Acceso a una representacin del recurso identificado por el URI. Correccin de errores Un agente repara un error para que dentro del sistema, es como si nunca se ha producido el error. Recuperacin de errores Un agente invoca excepcional comportamiento porque no corrija el error. Idioma extendido Si una lengua es un subconjunto del otro, este ltimo se llama lengua extendida. Identificador de fragmento La parte de un URI que permite la identificacin de un recurso secundario. Recursos de informacin Un recurso que tiene la propiedad que todas sus caractersticas esenciales pueden transmitir un mensaje.

Enlace Una relacin entre dos recurso cuando un recurso (representacin) se refiere a los otros recursos por medio de un URI. s Mensaje Una unidad de co municacin entre los agentes. Documento Namespace Un recurso de info rmacin identificado mediante un URI de Namespace de XML que contiene informacin til, mquina utilizable o humanos utilizable, sobre los trmino en un determinado espacio de nombres XML. Es til, aunque no s manditory, que el URI empleado co un espacio de nombres identifica a un do mo cumento de espacio de nombres. Representacin Datos que codifica la info rmacin sobre el estado del recurso. Recursos Cualquier cosa que po dra ser identificado mediante un URI. Interaccin segura Interaccin con un recurso do nde un agente no incurrir en ninguna obligacin ms all de la interaccin. Recursos secundarios Un recurso relacionado co otro recurso a travs del principal recurso con info n rmacin de identificacin adicio (el nal identificador de fragmento). Idioma del subconjunto Una lengua es un subconjunto de un segundo idio si cualquier documento en la primera lengua es tambin un ma documento vlido en el segundo idio y tiene la misma interpretacin en el segundo idioma. ma URI Acrnimo de Uniform Reso urce Identifier. Alias URI Dos o ms diferentes URIs que identifican el mismo recurso. Colisin de URI El uso de la misma URI para referirse a ms de un recurso en el co ntexto de pro colo Web y formatos. to s Propiedad URI Una relacin entre un URI y una entidad so cial, como una perso organizacin o especificacin. na, Persistencia de URI La expectativa social que una vez un URI identifica un recurso determinado, debe co ntinuar indefinidamente para referirse a ese recurso . Referencia URI Una abreviatura operacional de un URI. Identificador de recursos uniforme (URI) Un identificador global en el co ntexto de la World Wide Web. Interaccin inseguro Interaccin con un recurso que no es seguro. Agente de usuario Un tipo de agente Web; una pieza de software que acta en nombre de una perso na. WWW Acrnimo de World Wide Web. Web Fo rma abreviada de World Wide Web. Agente Web Una persona o una pieza de software que acta en el espacio de la informacin en nombre de una persona, entidad o proceso. World Wide Web Un espacio de informacin en la que se identifican elemento de inters por identificadores de recursos uniformes. s Formato basado en XML Uno que se ajusta a las reglas de sintaxis definidas en la especificacin de XML.

7. Referencias
CGI Especificacin de interfaz/1.1 de puerta de enlace comn. Disponible en http://ho o.ncsa.uiuc.edu/cgi/interface.html. oho FICHAS Problemas comunes de aplicacin HTTP, o. Threaux, enero de 2003. Esta presentacin del equipo de W3C est disponible en http://www.w3.org/TR/chips/. CUAP Problemas comunes de agente de usuario, k. Dubost, enero de 2003. Esta presentacin del equipo de W3C est disponible en http://www.w3.org/TR/cuap. Cool Cool URI no cambian T. berners-Lee, W3C, 1998 disponible en http://www.w3.org/Provider/Style/URI. Tenga en cuenta que el ttulo es un poco engaoso. No es el URI que cambiar, es lo que se identifican. Eng90 Interoperabilidad de dominio de conocimientos y un sistema abierto de Hyperdocument, D. C. Engelbart, de junio de 1990. HTTPEXT Extensiones obligatorias en HTTP, H. Frystyk Nielsen, p. Leach, Lawrence S., 20 de enero de 1998. Este proyecto caducada de Internet est disponible en http://www.w3.o rg/Protocols/HTTP/ietf-http-ext/draft-frystyk-http-mandatory. IANASchemes De IANA registro en lnea de esquemas de URI est dispo nible en http://www.iana.org/assignments/uri-schemes. IETFXML IETF directrices para el uso de XML en protocolos del IETF, S. Ho llenbeck, M. Rose, l. Masinter, eds., 02 de no viembre de 2002. Este proyecto de Internet est dispo nible en http://www.imc.org/ietf-xml-use/xml-guidelines-07.txt. Si este documento ya no est dispo nible, consulte la lista de co rreo de ietf uso de xml. INFOSET Conjunto de informacin XML (segunda edicin), r. To bin, j. Cowan, editores, recomendacin del W3C, 04 de febrero de 2004, http://www.w3.o rg/TR/2004/REC-xml-infoset-20040204. Versin ms reciente disponible en http://www.w3.org/TR/xml-infoset.

IRI IETF internacionalizados identificadores de recursos (IRIs), M. Drst, M. Suignard, eds., noviembre de 2004. En un anuncio de 08 de diciembre de 2004, el IESG aprob proyecto-duerst-iri-11 como un estndar propuesto de la IETF. Las referencias a la especificacin de IRI en un volumen de Arquitectura de la World Wide Web son para ese estndar propuesto. Una vez que el IETF emite una serie de Request For Comments (RFC) de la especificacin, esta recomendacin W3C puede actualizarse para referirse a ese RFC. Vase tambin la informacin ms reciente acerca de la especificacin de IRI. MEDIATYPEREG De IANA registro en lnea de los tipos de medios de Internet est disponible en http://www.iana.org/assignments/mediatypes/index.html. OWL10 Referencia del lenguaje OWL Web ontologa, M. Dean, g. Schreiber, editores, recomendacin del W3C, 10 de febrero de 2004, http://www.w3.org/TR/2004/REC-owl-ref-20040210/. Versin ms reciente disponible en http://www.w3.org/TR/owl -ref/. P3P10 La plataforma para la especificacin 1.0 de preferencias de privacidad (P3P1.0), M. Marchiori, Editor, recomendacin del W3C, 16 de abril de 2002, http://www.w3.org/TR/2002/REC-P3P-20020416/. Versin ms reciente disponible en http://www.w3.org/TR/P3P/. RDDL Lenguaje de descripcin de directorio de recursos (RDDL), j. Borden, T. Bray, eds., 01 de junio de 2003. Este documento est disponible en http://www.tbray.org/tag/rddl/rddl3.html. RDFXML Especificacin de la sintaxis de RDF/XML (revisado), D. Beckett, Editor, recomendacin del W3C, 10 de febrero de 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/. Versin ms reciente disponible en http://www.w3.org/TR/rdf-syntax-grammar. RELAXNG El proyecto de lenguaje de esquema de RELAX NG . RESTO Representacin estatal de transferencia (descanso), captulo 5 de la Tesis Doctoral "Estilos arquitectnicos y el diseo de arquitecturas de Software basadas en red", de r. T. Fielding, 2000. Diseadores de especificaciones del Protocolo en particular deben invertir tiempo en comprender el modelo de descanso y la pertinencia de sus principios para un diseo determinado. Estos principios incluyen la apatridia, asignacin de roles a las partes, espacio de direcciones uniforme y un limitado conjunto uniforme de verbos. Disponible en http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm. RFC2045 IETF RFC 2045: Extensiones multipropsito de correo Internet (MIME) Part One: formato de los mensajes de Internet, N. liberado, N. Borenstein, noviembre de 1996. Disponible en http://www.ietf.org/rfc/rfc2045.txt. RFC2046 IETF RFC 2046: Extensiones multipropsito de correo Internet (MIME) segunda parte: tipos de medios, N. liberado, N. Borenstein, noviembre de 1996. Disponible en http://www.ietf.org/rfc/rfc2046.txt. RFC2119 IETF RFC 2119: palabras clave para su uso en RFC para indicar niveles de exigencia, S. Bradner, marzo de 1997. Disponible en http://www.ietf.org/rfc/rfc2119.txt. RFC2141 IETF RFC 2141: sintaxis de URNA, r. Moats, mayo de 1997. Disponible en http://www.ietf.org/rfc/rfc2141.txt. RFC2326 IETF RFC 2326: tiempo Real (RTSP) Protocolo de transmisin, H. Schulzrinne, A. Rao, r. Lanphier, abril de 1998. Disponible en: http://www.ietf.org/rfc/rfc2326.txt. RFC2397 IETF RFC 2397: el esquema de URL "datos", l. Masinter, agosto de 1998. Disponible en: http://www.ietf.org/rfc/rfc2397.txt. RFC2616 IETF RFC 2616: Protocolo de transferencia de hipertexto - HTTP/1.1, j. Gettys, j. Mogul, H. Frystyk, l. Masinter, p. Leach, T. Berners-Lee, junio de 1999. Disponible en http://www.ietf.org/rfc/rfc2616.txt. RFC2717 IETF procedimientos de registro de nombres de esquema de URL, Petke r., i. rey, noviembre de 1999. Disponible en http://www.ietf.org/rfc/rfc2717.txt. RFC2718 IETF RFC 2718: directrices para nuevos esquemas de URL, l. Masinter, H. Alvestrand, m. Zigmond, r. Petke, noviembre de 1999. Disponible en: http://www.ietf.org/rfc/rfc2718.txt. RFC2818 IETF RFC 2818: HTTP Over TLS, e. Rescorla, mayo de 2000. Disponible en: http://www.ietf.org/rfc/rfc2818.txt. RFC3023 IETF RFC 3023: tipos de medios XML, M. Murata, S. Saint-Laurent, D. Kohn, enero de 2001. Disponible en: http://www.ietf.org/rfc/rfc3023.txt RFC3236 IETF RFC 3236: tipo de medio de la aplicacin/xhtml + xml, M. Baker, p. Stark, de enero de 2002. Disponible en: http://www.ietf.org/rfc/rfc3236.txt RFC3261 IETF RFC 3261: SIP: Protocolo de inicio de sesin, j. Rosenberg, H. Schulzrinne, g. Camarillo, et. otros, junio de 2002. Disponible en: http://www.ietf.org/rfc/rfc3261.txt RFC3920 IETF RFC 3920: mensajera Extensible y Protocolo de presencia (XMPP): ncleo, p. Saint-Andre, Ed., octubre de 2004. Disponible en: http://www.ietf.org/rfc/rfc3920.txt RFC977 IETF RFC 977: Protocolo de transferencia de noticias de red, B. Kantor, p. Lapsley, febrero de 1986. Disponible en http://www.ietf.org/rfc/rfc977.txt. SOAP12

SOAP versin 1.2 parte 1: marco de mensajera, j. Moreau, N. Mendelsohn, H. Frystyk Nielsen, et. al., editores, recomendacin del W3C, 24 de junio de 2003, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/. Versin ms reciente disponible en http://www.w3.org/TR/soap12-part1/. SVG11 Especificacin scalable Vector Graphics (SVG) 1.1, , j. Ferraiolo, D. Jackson, editores, recomendacin del W3C, 14 de enero de 2003, http://www.w3.org/TR/2003/REC-SVG11-20030114/. Versin ms reciente disponible en http://www.w3.org/TR/SVG11/. UNICODE The Unicode Consortium, el estndar de Unicode, versin 4, ISBN 0-321-18578-1, como actualizada de vez en cuando por la publicacin de las nuevas versiones. Consulte http://www.unicode.org/unicode/standard/versions para la ltima versin de Unicode e informacin adicional sobre las versiones de la norma y de la base de datos de caracteres Unicode. URI IETF identificadores uniformes de recursos (URI): sintaxis genrica, T. Berners-Lee, r. Fielding, l. Masinter, eds., septiembre de 2004. En un anuncio de 18 de octubre de 2004, el IESG aprob proyecto-fielding-uri-rfc2396bis-07 como un estndar completo del IETF. Las referencias a la especificacin de URI en un volumen de Arquitectura de la World Wide Web son que norma completa. Una vez que el IETF emite una serie de Request For Comments (RFC) de la especificacin, esta recomendacin W3C puede actualizarse para referirse a ese RFC. Vase tambin la informacin ms reciente acerca de la especificacin de URI. UniqueDNS IAB comentario tcnico en la raz DNS nica, B. Carpenter, 27 de septiembre de 1999. Disponible en http://www.icann.org/correspondence/iab-tech-comment-27sept99.htm. VOICEXML2 Voz Extensible Markup Language (VoiceXML) versin 2.0, B. Porter, A. Hunt, k. Rehor, et. al., editores, recomendacin del W3C, 16 de marzo de 2004, http://www.w3.org/TR/2004/REC-voicexml20-20040316/. Versin ms reciente disponible en http://www.w3.org/TR/voicexml20. XHTML11 XHTML 1.1 - basado en el mdulo XHTML, S. McCarron, M. Altheim, editores, recomendacin del W3C, 31 de mayo de 2001, http://www.w3.org/TR/2001/REC-xhtml11-20010531. Versin ms reciente disponible en http://www.w3.org/TR/xhtml11/. XLink10 Lenguaje de vinculacin de XML (XLink) versin 1.0, e. Maler, S. DeRose, D. Orchard, editores, recomendacin del W3C, 27 de junio de 2001, http://www.w3.org/TR/2001/REC-xlink-20010627/. Versin ms reciente disponible en http://www.w3.org/TR/xlink/. XML-ID xml:id versin 1.0, D. Veillard, j. Marsh, editores, proyecto de trabajo de W3C (work in progress), 07 de abril de 2004, http://www.w3.org/TR/2004/WD-xml-id-20040407. Versin ms reciente disponible en http://www.w3.org/TR/xml-id/. XML10 Extensible Markup Language (XML) 1.0 (tercera edicin), f. Yergeau, j. Paoli, C. M. Sperberg-McQueen, et. al., editores, recomendacin del W3C, 04 de febrero de 2004, http://www.w3.org/TR/2004/REC-xml-20040204. Versin ms reciente disponible en http://www.w3.org/TR/REC-xml. XML11 Extensible Markup Language ((XML)) 1.1, j. Paoli, C. M. Sperberg-McQueen, j. Cowan, et. al., editores, recomendacin del W3C, 04 de febrero de 2004, http://www.w3.org/TR/2004/REC-xml11-20040204/. Versin ms reciente disponible en http://www.w3.org/TR/xml11/. XMLNS Espacios de nombres XML 1.1, r. Tobin, D. Hollander, A. laico, et. al., editores, recomendacin del W3C, 04 de febrero de 2004, http://www.w3.org/TR/2004/REC-xml-names11-20040204. Versin ms reciente disponible en http://www.w3.org/TR/xml-names11/. XMLSCHEMA XML Schema parte 1: estructuras, D. Beech, M. Maloney, H. S. Thompson, et. al., editores, recomendacin del W3C, 02 de mayo de 2001, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/. Versin ms reciente disponible en http://www.w3.org/TR/xmlschema-1/. XPTRFR Marco del XPointer, e. Maler, N. Walsh, p. Grosso, et. al., editores, recomendacin del W3C, 25 de marzo de 2003, http://www.w3.org/TR/2003/REC-xptr-framework-20030325/. Versin ms reciente disponible en http://www.w3.org/TR/xptr-framework/. XSLT10 XSL Transformations (XSLT) Version 1.0, j. Clark, Editor, recomendacin del W3C, 16 de noviembre de 1999, http://www.w3.org/TR/1999/REC-xslt-19991116. Versin ms reciente disponible en http://www.w3.org/TR/xslt.

7.1. Especificaciones de la arquitectura

ATAG10 Authoring Tool Accessibility Guidelines 1.0, C. McCathieNevile, i. Jacobs, j. Treviranus, et. al., editores, recomendacin del W3C, 03 de febrero de 2000, http://www.w3.org/TR/2000/REC-ATAG10-20000203. Versin ms reciente disponible en http://www.w3.org/TR/ATAG10. CHARMOD Modelo de caracteres para el World Wide Web 1.0: fundamentos, r. Ishida, M. j. Drst, M. Wolf, et. al., editores, W3C trabajando proyecto (work in progress), 25 de febrero de 2004, http://www.w3.org/TR/2004/WD-charmod-20040225/. Versin ms reciente disponible en http://www.w3.org/TR/charmod/. DIPRINCIPLES Principios de independencia de dispositivo, r. Gimson, Editor, W3C nota, 01 de septiembre de 2003, http://www.w3.org/TR/2003/NOTE-di-princ-20030901/. Versin ms reciente disponible en http://www.w3.org/TR/diprinc/. EXTLANG Arquitectura web: idiomas extensibles, T. Berners-Lee, D. Connolly, 10 de febrero de 1998. Esta nota del W3C est disponible en http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210. Fielding

Diseo de principio de la arquitectura moderna Web, R.T. Fielding y R.N. Taylor, UC Irvine. En los procedimientos de la Conferencia Internacional sobre ingeniera de Software (ICSE 2000), Limerick, Irlanda, junio de 2000, pgs. 407-416. Este documento est disponible en http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf. QA Marco de control de calidad: directrices de especificacin, D. Hazal-Massieux, l. Rosenthal, l. Henderson, et. al., editores, W3C trabajando proyecto (work in progress), 30 de agosto de 2004, http://www.w3.org/TR/2004/WD-qaframespec-20040830/. Versin ms reciente disponible en http://www.w3.org/TR/qaframe-spec/. RFC1958 IETF RFC 1958: principios de la arquitectura de Internet, B. Carpenter, junio de 1996. Disponible en http://www.ietf.org/rfc/rfc1958.txt. SPECVAR La variabilidad en especificaciones, l. Rosenthal, D. Hazal-Massieux, editores, W3C trabajando proyecto (work in progress), 30 de agosto de 2004, http://www.w3.org/TR/2004/WD-spec-variability-20040830/. Versin ms reciente disponible en http://www.w3.org/TR/spec-variability/. UAAG10 Directrices de accesibilidad de agente de usuario 1.0, j. Gunderson, i. Jacobs, e. Hansen, editores, recomendacin del W3C, 17 de diciembre de 2002, http://www.w3.org/TR/2002/REC-UAAG10-20021217/. Versin ms reciente disponible en http://www.w3.org/TR/UAAG10/. WCAG20 2.0 De las directrices de accesibilidad de contenido web, w. Chisholm, j. White, B. Caldwell, et. al., editores, W3C trabajando proyecto (work in progress), 30 de julio de 2004, http://www.w3.org/TR/2004/WD-WCAG20-20040730/. Versin ms reciente disponible en http://www.w3.org/TR/WCAG20/. WSA Arquitectura de servicios web, D. Booth, f. McCabe, recin llegado de e., et. al., editores, nota W3C, 11 de febrero de 2004, http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/. Versin ms reciente disponible en http://www.w3.org/TR/ws-arch/. XAG Las directrices de accesibilidad de XML, S. B. Palmer, C. McCathieNevile, D. Dardailler, editores, W3C trabajando proyecto (work in progress), 03 de octubre de 2002, http://www.w3.org/TR/2002/WD-xag-20021003. Versin ms reciente disponible en http://www.w3.org/TR/xag.

8. Agradecimientos
Este documento fue elaborado por el grupo de la arquitectura tcnica de W3C que inclua los siguientes participantes: Tim Berners-Lee (copresidente, W3C), Tim Bray (sistemas de la Antrtida), Dan Connolly (W3C), Paul Cotton (Microsoft Corporation), Roy Fielding (Day Software), Mario Jeckle (Daimler Chrysler), Chris Lilley (W3C), Noah Mendelsohn (IBM), David Orchard (BEA Systems), Norman Walsh (Sun Microsystems) y Stuart Williams (copresidente, Hewlett-Packard). La etiqueta agradece las muchas contribuciones de lista de correo pblica la etiqueta, www-tag@w3.org (archivo), que han ayudado a mejorar este documento. Adems, las contribuciones de David Booth, Erik Bruchez, Kendall Clark, Karl Dubost, Bob DuCharme, Martin Duerst, Olivier Fehr, Al Gilman, Tim Goodwin, Elliotte Rusty Harold, Tony Hammond, Sandro Hawke, Ryan Hayes, Dominique HazalMassieux, Masayasu Ishikawa, David M. Karr, Graham Klyne, Jacek Kopecky, Ken Laskey, Susan Lesch, Hkon Wium Lie, Frank Manola, Mark Nottingham, Bijan Parsia, Peter F. Patel-Schneider, David Pawson, Michael Sperberg-McQueenStickler Patrick y Yuxiao Zhao se reconocen con gratitud.