At 2004-02-10 10:52 +1000, CRANSTON, Dalton wrote:
>One of the barriers to transition from proprietary systems is the
>of a suitable, cost effective migration path for pre-existing templates.
That would be "for pre-existing proprietary templates" which, by
definition, would make them difficult animals to find since they'd be the
domain of proprietary vendors that may not have an interest in open solutions.
>One of these systems is Xerox Autograph where we use DLS and Compuset
>templates to produce statements etc. I have found Compuset to PDF
>converters but really what I want is to be able to (somehow) convert the
>templates to interim formats such as XML+XSLT (to produce XSL-FO)
I believe that is a tough nut to crack, not because of any complexity that
might be with XSLT and XSL-FO ... these are designed well for what they do
and the meet a set of semantics designed and selected by the working group
that developed the specification.
>rather than to some end format as I would like to be able to then use
>them at design time into the future.
Gee, sounds nice, but won't it be difficult to map a vendor's proprietary
choice of layout semantics to an open standard's choice of layout
semantics? Certainly the end results of many of the concepts will be
similar since both are producing a paginated output, but how it gets there
is critically important because any expression you may have that follows
the semantics of a proprietary solution would have to be interpreted and
translated to an expression that follows the semantics of XSLT and XSL-FO.
This is not to speak to the architectural chasm between tightly-bound
formatting processors where the transformation task is intimately aware of
the formatting task, and the XSL arm's-length architecture where all of the
transformation has to be completed before any of the formatting can
begin. You will have to find a way to map all of the proprietary semantics
of on-the-fly status checking into XSL's semantics of formatting contingencies.
One important question is: does the proprietary system have a concept of
transformation of XML inputs to an output, or is it similar to a desktop
publishing system of production of a final-form output?
>Does anyone have any ideas or suggestions on this?
(1) Manage your expectations ... without even knowing your proprietary
systems, I suspect it will either take magic or human intervention to map
(2) If you can at the least produce a static XSL-FO instance representing
the same output as that of a proprietary solution, then consider how
LiterateXSLT (a free resource available from our web site) might help; it
is an incomplete prototype of XSLT stylesheet inference engine. Using
LiterateXSLT one makes a static snapshot of a completed transformation,
then seeds that snapshot with triggers about transformation based on a
representative XML input. A multi-step process then infers the XSLT
stylesheet required for the XML input to generate the XSL-FO output. That
XSLT stylesheet can then be used with multiple XML inputs. I developed the
prototype long enough to satisfy some UBL work I was doing and then left it
on the shelf for others since I don't have the resources to complete
it. Others have found it useful.
I hope this has helped.
Public courses: upcoming world tour of hands-on XSL training events
Each week: Monday-Wednesday: XSLT/XPath; Thursday-Friday: XSL-FO
Washington, DC: 2004-03-15 San Francisco, CA: 2004-03-22
Hong Kong: 2004-05-17 Germany: 2004-05-24 England: 2004-06-07
World-wide on-site corporate, government & user group XML training!
G. Ken Holman mailto:gkholman@...
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/f/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/f/bc