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

[michael odling-smee <mike.odlingsmee@gmail.com>]

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@gmail.com> wrote:

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

_______________________________________________________________________

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@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php