Another $0.02:
At 05:14 AM 8/21/2004, Jeni wrote:
You have two options:
1. Use a core format, write code to generate HTML (or whatever) from
that format, and write code to convert from each of the other formats
into that core format:
TEI ---------------|
DocBook --------v v
OpenOffice --> core format ----> XHTML
WordML ---------^ ^
MODS --------------|
Each of the transformations is likely to be relatively easy to write
and to debug; you have to write a lot of them, but you can do it as
the requirement arises.
This architecture could certainly be rearranged to have OpenOffice be your
ultimate target. (While I'm a fan of OpenOffice, however, I don't find its
own XML to be robust and descriptive enough to be the mediating core format
here, however -- though I suppose that could be changed, which is a big
reason I like OpenOffice.)
I concur with Jeni's implication that this is easier to manage and maintain
than the yet-another-metalanguage solution involving configuration-driven
stylesheet-generation.
Where I disagree with Jeni is in the assessment that it's likely to be easy
to write and debug each of these transforms. The 80% of any one of them may
be easy to write and debug, but the 20% will not, and it will always be a
different 20%, due to the inescapable fact that the models proposed by
these different inputs will not see eye to eye. (To say nothing of the fact
of life that, particularly in heterogeneous environments, more often than
not real instances fall short of the perfection of their presumed models.)
For example, if your target format distinguishes between "books" and
"monographs" but one of your inputs does not, do you make them all books,
or all monographs? and either way, haven't you just lost your distinction?
It will be quite a technical and marketing achievement to come up with a
solution that is so comprehensive, serviceable and user-friendly that it
can compete with the widespread *belief* that Word and Endnote are up to
the job already (as opposed to competing with the reality that they are
sadly not, and that bibliography work in the present day always requires
non-trivial custom coding and/or hand-fixing at least to some extent).
In this case, I'm a guy with a glass that's half empty. Not that I wouldn't
be happy to be proven wrong.
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
======================================================================