Structure maintenance

Introducing backward compatible structure changes in the system is usually quite easy, since they don’t break the validity of any document.

Examples on backward compatible changes:

• new element with optional occurrence
• existing element with less restricted occurrence

Backward incompatible changes are more challenging. Obviously we want to keep our documents valid.

Can we update the documents to the new structure via an automated conversion? If yes, then we need to loop through all the documents and execute this conversion on them one by one. If our CMS supports this operation out of the box, then we’re lucky. If it does not, then we have to do a remigration: export the content out, convert it and then import it again.

If the conversion cannot be automated, but human editors have to change the content, then temporarily we should allow both the old and the new substructures in the schema and when the job is done for all the documents, then we can safely remove the old deprecated substructure from the schema to keep it clean.

Almost safely... since we should not forget about the old document versions either. Old document versions should still validate against the schema, otherwise we loose control on them. Then there is one option to introduce a new version of the schema (DTD or XSD). Old document versions validate against the old schema version while the new (actual) document versions validate against the new schema version.

By doing this we likely sacrifice the rollback operation to the old versions, but I guess there is no perfect way to handle this. The backward incompatible schema change will also force us to change our publishing scripts and it keeps things simple if we get rid of the publishing code dealt with the old structure right away.