Hello Lech,

Just to clarify - do your end users edit the XML directly? The reason I ask
is whether your users would be happy to look at any raw XML diff (e.g. using
the diff tooling in Eclipse which typically integrated with version
control), or are you expecting to produce a nice diff. report that
accessible to non-XML savvy audiences.

For my use-case I am concentrating on the latter. I am envisaging that the
tooling would produce an XML diff. report that would be converted into
readable form via XSL.

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

This is definately a challenge.

The first thing that is necessary is some identifier in the instance
document that declares what version of the data model the instance document
adheres to. As part of the general tooling for my project I also provide
upgrade tooling that converts all instance documents into the latest version
of the data model. The upgraded instance could then be used as the input to
the differencing tool.

Now this approach assumes that there is a syntactic / semantic upgrade path
- i.e. that the latest data model is backwards compatible. As James points
out this may not always be true and something more sophisticated may be
required. At the very least having the data model version identifier will
allow any tool to recognise what documents it cannot automatically compare.

Michael

On Fri, Oct 2, 2009 at 9:59 AM, James Fuller <james.fuller.2007@g...>wrote:

> On Fri, Oct 2, 2009 at 10:46 AM, Lech Rzedzicki <xchaotic@g...>
> wrote:
> > On Thu, Oct 1, 2009 at 5:29 PM, James Fuller
> > <james.fuller.2007@g...> 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
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>