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(_at_)reallysi(_dot_)com>
wrote:
On 10/13/09 12:13 PM, "Vyacheslav Sedov"
<vyacheslav(_dot_)sedov(_at_)gmail(_dot_)com> 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(_at_)reallysi(_dot_)com
<mailto:ekimber(_at_)reallysi(_dot_)com>
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>
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--