Re: [xsl] keys and variables

Subject: Re: [xsl] keys and variables
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Mon, 23 Aug 2004 14:49:35 -0400
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 ======================================================================

Current Thread