bueno o comunes convenios de denominación de espacio de nombres XML URIs

Question

Estoy buscando algunas ideas para buenos convenios de denominación de espacios de nombres de destino xsd.

Básicamente, sólo tiene que tomar una decisión definitiva sobre la manera de nombrar el espacio de nombres de mi xsd así que trato de hacerlo bien la primera vez. Cambiarlo más tarde requeriría cambios en otro sistema que no está bajo mi control.

¿Tiene alguna experiencia de creaciones de esquema XML pasado en lo que es una buena solución y trabajar? Intenté encontrar información en línea, pero la mayoría de los ejemplos solo usan espacios de nombres de destino muy genéricos como "http: // exampleSchema" y similares. En realidad estoy tratando de encontrar algunos ejemplos de la vida real.

Answer 1

propias prácticas de W3C para la selección de larga vida URI son un buen punto de partida para los URI de espacio de nombres XML. Consulte Cool URIs don't change para obtener algunas sugerencias, con la excepción de que un URI de espacio de nombres no necesita ser recuperado y, por lo tanto, es posible que algunas de esas directrices no se apliquen.

• utilizar un prefijo que está inequívocamente ligado al propietario especificación como el URI del servidor Web. Si el esquema estará disponible en línea, es un buen toque si se puede encontrar en su nombre URI. El uso de URL HTTP no es obligatorio, aunque es una práctica común.
• Incluya una fecha aproximada después de (el año y el mes son buenos) por lo que si en el futuro reorganiza su espacio de nombres, la antigüedad del nombre (y por lo tanto su organización interna) no es ambigua. Tenga en cuenta que esta es la fecha en que se asignó por primera vez el URI, no la fecha de la versión actual.
• añadir un nombre de para identificar la materia objeto de este esquema concreto, por lo que se le puede decir de otros esquemas relacionados. Este nombre debe ser inmutable, incluso si el nombre comercial del tema tiene que cambiar. Tal vez alguien más que tenga una marca registrada en él te haya sorprendido, tal vez el departamento de ventas quiera probar un nuevo giro, pero el código no debería romperse.
• Por último, si las versiones posteriores del mismo esquema conceptual no son compatibles, agrega un componente único de control de versiones para indicar el rompimiento de compatibilidad. Si el control de versiones se maneja dentro del alcance del vocabulario (por ejemplo, mediante un atributo de versión), por otro lado, omita esto.

XSLT utiliza la siguiente:

http://www.w3.org/1999/XSL/Transform 

Esto se ajusta el patrón anterior. Identificador del propietario, fecha y nombre; y ningún componente de control de versiones porque el control de versiones se maneja dentro del vocabulario XSLT.

En caso de necesidad, incluso puede salirse con la

mailto:author@example.org?Subject=2008+XML+Basketweaving+specification 

que encaja el patrón también, pero sugiere un punto de contacto en lugar de un repositorio de información.