¿Cuáles son las mejores prácticas para versionar esquemas XML?

A menudo tengo que diseñar esquemas XML para diferentes rutinas de importación de bases XML. Está claro que los esquemas XML evolucionarán con el tiempo o podrían contener errores por corregir, por lo que es importante capturar la versión del esquema y tener algún mecanismo para enlazar con una versión específica.

Actualmente tengo dos escenarios:

  1. El error se encuentra dentro del esquema y todas las instancias de esquema deben cumplir con la versión fija.

  2. El esquema se actualizó y debe considerarse como preferible, pero también debería admitirse uno antiguo.

Finalmente se me ocurrió almacenar la información de la versión dentro del espacio de nombre del esquema:

targetNamespace="http://schemas.company.com/Geodesy/2010/River.xsd" 

Al corregir un error, lo soluciono en el mismo espacio de nombres, pero si estoy a punto de actualizar un esquema, entonces necesito crear un nuevo espacio de nombres pero con el mes de actualización agregado:

 targetNamespace="http://schemas.company.com/Geodesy/2010/01/River.xsd" 

Y si tengo más de una actualización en un mes, solo agregue un día también:

 targetNamespace="http://schemas.company.com/Geodesy/2010/01/17/River.xsd" 

¿Conoces algún mejor enfoque?

Este es un tema tan difícil que ni siquiera es divertido, y que he pasado años brindando apoyo de consultoría.

Existen muchas mejores prácticas , pero la mayoría de ellas no funcionan en todas las situaciones. Por ejemplo, muchos abogan por el uso de “xsd: any” para permitir extensiones, y eso es solo una receta para el desastre si los desarrolladores están a cargo de mantener el esquema, convirtiéndolo en un vertedero.

Aquí hay algunos consejos para usted si está comenzando:

  • No ponga un número de versión menor, número de versión micro, fecha u otra cosa del género en su espacio de nombres. Cada vez que cambie el espacio de nombres, romperá todas las aplicaciones de procesamiento.
  • Ponga un atributo de “versión” en el documento de instancia XML. Eso permitirá que una aplicación de procesamiento o un servicio de adaptador de versión descubra qué se está procesando.
  • Especifique una política de lo que constituye un cambio retrocompatible, por ejemplo: añadir elementos opcionales no afectará a los remitentes, y tampoco romperá los receptores si usan una política de ignorar elementos que no conocen (JAXB y XMLBeans se pueden configurar de esta manera )

¡Buena suerte!

http://www.xml.com/pub/a/2004/07/21/design.html proporciona buenas pautas y XML Schema 1.1 habilita el ‘versionado’ a través de la inclusión condicional ( http://www.w3.org/TR/ xmlschema11-1 / # cip ).