[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Profiling, diff and change tracking best practices?

• From: James Fuller <james.fuller.2007@gmail.com>
• To: Lech Rzedzicki <xchaotic@gmail.com>
• Date: Fri, 2 Oct 2009 10:59:42 +0200

On Fri, Oct 2, 2009 at 10:46 AM, Lech Rzedzicki <xchaotic@gmail.com> wrote:
> 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.
>

I have done this before using XSLT to generate final schemas ... its
not ideal but it did mean I had a single meta source of schema
information.

>> 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.

as it happens I see Jirka later on today and will ask him if he knows
of anything ... also have u seen Florent Georges new expath packaging
mechanism, wondering if there is any potential for shaping his
packaging approach to include schema migration.

all interesting stuff ... may I ask that (if interested and coming in
2010) that you submit this as a possible XML Prague topic (when we
call for papers) .... we are preparing a few comms on XML Prague for
release soon.

J

• Follow-Ups:
  • Re: Profiling, diff and change tracking best practices?
    • From: michael odling-smee <mike.odlingsmee@gmail.com>

• References:
  • Profiling, diff and change tracking best practices?
    • From: Lech Rzedzicki <xchaotic@gmail.com>
  • Re: Profiling, diff and change tracking best practices?
    • From: James Fuller <james.fuller.2007@gmail.com>
  • Re: Profiling, diff and change tracking best practices?
    • From: Lech Rzedzicki <xchaotic@gmail.com>