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 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>
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XML to both ODF and OOXML, ekimber | Thread | Re: [xsl] XML to both ODF and OOXML, Xmlizer |
[no subject], Unknown | Date | Re: [xsl] XML to both ODF and OOXML, Xmlizer |
Month |