OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Profiling, diff and change tracking best practices?

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

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS