[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Another $0.02:
At 05:14 AM 8/21/2004, Jeni wrote:
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.
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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] modularity and flexibility (w, Bruce D'Arcus | Thread | [xsl] xslt and citations in openoff, Bruce D'Arcus |
Re: [xsl] keys and variables, Wendell Piez | Date | Re: [xsl] keys and variables, Wendell Piez |
Month |