¿Cómo debo administrar diferentes formularios incompatibles de documentos basados ​​en Xml?

Question

Tengo una aplicación que guarda documentos (piense en documentos word) en un formato Xml. Actualmente, las clases C# generadas a partir de archivos xsd se utilizan para leer/escribir el formato del documento y todo estuvo bien hasta hace poco cuando tuve que hacer un cambio en el formato del documento. Mi preocupación es la compatibilidad con versiones anteriores ya que las versiones futuras de mi aplicación necesitan para poder leer documentos guardados por todas las versiones anteriores y, idealmente, también quiero que las versiones anteriores de mi aplicación puedan manejar documentos de lectura guardados en versiones futuras de mi aplicación

Por ejemplo, suponiendo que cambie el esquema de mi documento de añadir una (opcional) elemento extra en alguna parte, versiones a continuación antiguas de mi aplicación simplemente ignorar la elemnt extra y no habrá ningún problema:

<doc> 
    <!-- Existing document --> 
    <myElement>Hello World!</myElement> 
</doc> 

Sin embargo, si se realiza un cambio radical (un atributo se cambia en un elemento, por ejemplo, o una colección de elementos), las versiones anteriores de mi aplicación deben ignorar este elemento si es opcional o informar al usuario que están intentando para leer un documento guardado con una versión más nueva de mi aplicación de lo contrario. También esto me está causando dolores de cabeza ya que todas las versiones futuras de mi aplicación necesitan un código completamente separado para leer los dos documentos diferentes.

Un ejemplo de tal cambio sería el siguiente código XML:

<doc> 
    <!-- Existing document --> 
    <someElement contents="12" /> 
</doc> 

Cambiar a:

<doc> 
    <!-- Existing document --> 
    <someElement> 
     <contents>12</contents> 
     <contents>13</contents> 
    </someElement> 
</doc> 

Con el fin de prevenir los dolores de cabeza de apoyo en el futuro que quería llegar a una decente estrategia para manejar los cambios que podría hacer en el futuro, de modo que las versiones de mi aplicación que lanzo ahora puedan hacer frente a estos cambios en el futuro:

• ¿Debe guardarse el "número de versión" del documento en el documento y, de ser así, qué estrategia de control de versiones debe usarse? Si la versión del documento coincide con la versión del ensamblado .exe, o si se debe usar una estrategia más compleja (por ejemplo, revisión mayor cambiada indica cambios de interrupción, cuando los incrementos menores de revisión indican cambios sin interrupción, por ejemplo, elementos adicionales opcionales)
• What ¿Debería usar el método para leer el documento y cómo evitar la duplicación de grandes cantidades de código para diferentes versiones de documentos?
  • Aunque XPath es obviamente más flexible, es mucho más trabajo de implementar que simplemente generar clases con xsd.
  • Por otro lado, si se utiliza el análisis DOM, entonces se necesitaría una nueva copia del documento xsd en el control de origen para cada cambio de interrupción, causando problemas si las correcciones alguna vez se deben aplicar a esquemas anteriores (las versiones anteriores de la aplicación todavía compatible).

Además, he trabajado todo esto muy loosly en el supuesto de que todos los cambios que realice se pueden dividir en dos categorías de estos "cambios Beaking" y "cambios" no separación, pero estoy no del todo convencido de que es una suposición segura de realizar.

Tenga en cuenta que utilizo el término "documento" muy vagamente: ¡el contenido no se parece en nada a un documento!

Gracias por cualquier consejo que me puede ofrecer.

Answer 1

Definitivamente necesita un número de versión en el archivo XML, y sugeriría no vincularlo a la versión de la aplicación porque es realmente una entidad separada. Puede hacerlo a través de dos o tres versiones de su aplicación sin cambiar el formato XML o puede terminar cambiando el formato varias veces durante el desarrollo de una sola versión.

Si desea que las versiones anteriores de la aplicación puedan leer versiones más nuevas del archivo XML, nunca podrá eliminar elementos ni cambiar sus nombres. Siempre puede agregar elementos y el código antiguo los ignorará felizmente (una de las bonitas funciones de XML) pero si los elimina, el código anterior no podrá funcionar.

Como dijo Ishmael, XSLT es una buena forma de convertir el formato XML de una versión a otra para que no termines con un montón de rutinas de análisis en tu código fuente.

Answer 2

¿Podría agregar un atributo a la versión que especifica el elemento raíz?

De esta manera, las versiones anteriores no se romperán, y las versiones más recientes de su software verán el atributo y cambiarán a un método de carga diferente de manera apropiada.

La numeración de la versión en sí dependerá de la frecuencia de su lanzamiento. Yo personalmente iría con el número de versión principal de su software, a menos que prevea que el formato cambie más a menudo que eso.

Editar: apenas se dio cuenta de lo de la duplicación de código:

Para que iba a utilizar el patrón de la fábrica, algo como esto:

LoadDocument 
DoNonVersionDependingLoading 
VersionSpecificLoaderFactory(VersionNumber) 

Answer 3

XSLT es una elección obvia aquí. Dado que puede identificar la versión de su documento, para cada versión de su esquema, cree un XSLT que transforme la versión anterior a su nueva versión.

Puede aplicar las transformaciones en secuencia hasta llegar a la versión actual. Por lo tanto, solo edita la última versión del documento. Por supuesto, no podrá guardar el formato anterior y puede romper el documento para versiones anteriores, pero esto es típico de muchas aplicaciones. Si es absolutamente necesario guardar en la versión anterior, simplemente cree una transformación que vaya en la otra dirección.

Como dice @Andy, use el número de versión principal de su aplicación.