Re: [xml-dev] Profiling, diff and change tracking best practices?

[Lech Rzedzicki <xchaotic@gmail.com>]

On Thu, Oct 1, 2009 at 5:29 PM, James Fuller
<james.fuller.2007@gmail.com> wrote:
> Hello Lech,

Hi Jim, good to hear from you.
> Another approach would be to use version control of one sort or
> another ... eXist has a versioning extension and MarkLogic has
> something akin to this in a library module (if u have access to
> MarkLogic), otherwise any source control will give you what you want.

We are using xhive with version control anyway, my aim here is to make
the schema vendor-independent so should we choose to migrate to eXist
or ML we're not too heavily dependent on the vendor-specific metadata.

> As with any data structure, if the underlying schema itself is
> volatile then you can experience pain in the form of backwards
> incompatibility ... so if you do go down the route of embedding
> version metadata you may want to test what happens when you change
> your schema and how to mitigate the impact of such things on your
> version metadata.

Agreed fully and that's why I try the impossible and cater for all the
scenarios that I have come across before and folks at the company have
not discovered yet. Another feature of the schema is to be able to
produce variants easily through a customisation that follows a bit
Docbook  customisation strategy [1] but also incorporates the
DITA-like concept of specialisation and uses remap to be able to
publish back in original docbook as suggested by Norm and implemented
by Jirka which should take care of at least few incompatibility
problems as it is always going to be a requirement to be able to
publish to clean DB5 from any variant. Another measure we've taken is
incorporating migration tasks in our resource estimates so that the
toolkit to migrate to and from the existing schema will just be a part
of a new schema delivery.

[1] http://www.sagehill.net/docbookxsl/CustomDb5Xsl.html
[2] http://xmlguru.cz/2006/03/easy-docbook-specialization

Lech