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

[Vyacheslav Sedov <vyacheslav.sedov@xxxxxxxxx>]

i am also prefer point 2 - and i am looking for something like NLM 3.0
DTD http://dtd.nlm.nih.gov/publishing/3.0/ 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>
wrote:
>
>> 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
formats)
>> 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 http://odf-converter.sourceforge.net/ still not
>> work as expected - too many bugs)
>
> I would normally pursue option 2 since it's reasonably easy to abstract
from
> 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
> www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
> <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>