Re: [xsl] XML to both ODF and OOXML conversion

Subject: Re: [xsl] XML to both ODF and OOXML conversion
From: Vyacheslav Sedov <vyacheslav.sedov@xxxxxxxxx>
Date: Wed, 14 Oct 2009 11:53:59 +0400
i am also prefer point 2 - and i am looking for something like NLM 3.0
DTD as intermediate format - is
it good idea?

Look like i am capable to implement XSLT for lossless roundtrip
editing for NLM articles in OO & MS Word.

By the way - in case of XML-DB it is look better to store content of
documents in NLM-like format too

On Tue, Oct 13, 2009 at 9:25 PM, ekimber <ekimber@xxxxxxxxxxxx> wrote:
> On 10/13/09 12:13 PM, "Vyacheslav Sedov" <vyacheslav.sedov@xxxxxxxxx>
>> Hi,
>> Our system should generate both formats from custom XML to ODF and OOXML
>> Need advice about best workflow
>> option 1 is XML -> ODF and XML -> OOXML (independent XSLT for both
>> option 2 is XML -> intermediate format (maybe as mixed namespaces from
>> ODF, OOOXML, XHTML, MathML) then two XSLT for ODT & OOXML
>> option 3 is XML -> ODT -> OOXML (look like not so simple as expected,
>> 3rd party XSLT see still not
>> work as expected - too many bugs)
> I would normally pursue option 2 since it's reasonably easy to abstract
> any word processing format into a generic "paragraphs and inlines" format
> that is then an easier map to specific tools' formats. However, that may be
> more true when coming *from* such formats, where many details can be
> ignored, than it is for going to such formats.
> From an engineering standpoint I would be tempted to start with a complete
> path for one target and then start implementing the second path and see if
> any obvious commonalities fall out that would be worth the cost of
> refactoring into a two-phase process involving an intermediate format.
> If you haven't already, you should think carefully about how you
> parameterize and enable extension of the mapping from the input XML to the
> the result target.
> I've addressed this a generic transform that supports going from DITA to
> InDesign by using a separate mode that does nothing but map elements to
> style names. The mode itself is used from a function that takes and element
> and returns its result style name. This keeps the using templates simple.
> This allows for easy extension for custom mappings while keeping the
> implementation cost low, both for my base transform and for implementors,
> since the custom templates are just a match statement and a string result.
> The alternative would be some sort of configuration file mechanism, but I
> quickly ran into the problem that I'd need to support arbitrary match or
> select capability, and at that point you might as well stick with XSLT
> itself.
> Cheers,
> Eliot
> ----
> Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
> email:  ekimber@xxxxxxxxxxxx <mailto:ekimber@xxxxxxxxxxxx>
> office: 610.631.6770 | cell: 512.554.9368
> 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
> <>  |
> <> | <>

Current Thread