Re: [xsl] XSLT workflow: ODF <-> XPP

Subject: Re: [xsl] XSLT workflow: ODF <-> XPP
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Thu, 28 May 2009 11:54:15 -0400
Hi Martynas,

At 07:32 PM 5/27/2009, you wrote:
this is more of a general question about XSLT workflow than a specific
task or technique.

Well ... kind of. It's not really on topic, unfortunately, since you'd have this problem irrespective of whether XSLT were part of the picture or not. Migrating your transformations to XSLT might be a good idea for other reasons, but it won't make this set of problems go away.

The basic problem you face is that you are relying on two systems, XPP and OpenOffice, neither of which (for all their virtues) is really designed or intended to support an open workflow such as you describe.

This means that while XML by itself gives you a certain measure of data interchangeability, nevertheless there is plenty of vital information that is hard to get across from one tool to another, and back again. (For example, those XPP-native processing instructions.)

The issue is complicated because you are actually using at least one of these tools, OpenOffice, for more than one thing. You get information from authors in its format. You then produce PDFs using XPP, during which you (sometimes) edit the content. Then you move the edited content back into OpenOffice for the XHTML and ePub step.

One simple adjustment you could make would be to isolate your usage of OpenOffice the first and second time from one another. As long as they are not isolated, it is too easy to make changes in OpenOffice and get out of synch with XPP.

Similarly, you could simplify by determining which of your systems is actually going to be your editorial platform. You need to do this since not defining one system as the authoritative location for editorial work means that your content sloshes all over the place -- any time a change is made anywhere, the data needs to migrate throughout the system of systems again. Even if all the transformations were perfect, this would pose a big data management and versioning problem. Determining where you will have a "hub" editorial platform can help to mitigate and contain this, if not make it go away absolutely. This would help you define and prioritize exactly what requirements for round-tripping your data you actually have.

What it comes down to is that this is a workflow and data management design problem, not a transformation problem. Indeed, until you really start looking at it like this -- and assuming that your use of either or both OpenOffice and XPP continues to evolve, as it surely must -- the transformation problems are likely to be impossible to define adequately, much less deal with.


Maybe some version control could help? Or is it crazy to
think about manuscripts as source code?

It will surely help, once you decide where the control points have to be. No, it isn't crazy to think about manuscripts as source code, particularly since source code, at least as far as versioning is concerned, is really nothing more than a sort of manuscript.


Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.      
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
  Mulberry Technologies: A Consultancy Specializing in SGML and XML

Current Thread