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.
Finally,
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.
Cheers,
Wendell
======================================================================
Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc. http://www.mulberrytech.com
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
======================================================================