If all of your formatting requirements are met by both XSLT/XSL-FO
and Jaspersoft, then you will have to try and leverage "soft" benefits:
(1) - multiple independent vendors of XSLT/XSL-FO engines, thus not
having single supplier problems (should, say, the supplier stop
supporting the tool you are using)
(2) - multiple independent sources of XSLT/XSL-FO training and
resource materials (for example we sell books on XSLT and XSL-FO and
a video on XSLT (which includes a copy of the book))
(3) - multiple applications of XSLT/XSL-FO expertise to other areas
of your business (should, say, you wish to produce technical manuals
that are not created by a "report generator") will leverage any
investment you make in learning XSLT/XSL-FO or buying XSLT/XSL-FO
technologies to other areas of your company
You may wish to play up the features of XSL-FO, such as flexibly
adding hyperlinks to your reports, alphabetized indexes and tables of
content, etc. if these are features not available with JasperSoft or
are not easy or flexible to use.
I'm assuming that since you are looking at XSLT that your source
content is already in XML. Compare and contrast working with XML
from C++ and C to working with XML from XSLT and XQuery: XSLT is
designed *for* XML and its expression language manifests the result
you want by using XML syntax. This is unlike programming languages
where XML is an add-on to the language accessed through a subroutine
library. I would far more trust the integrity of the transformation
of XML and its result when using XSLT and its inherent XML than
trying to make sure I remembered to do everything right for XML when
using another programming language.
Just some thoughts. I don't always win the fight with the above
arguments as it is difficult to sway adherents of other languages who
fail to see the light about XML and XSLT. Then again, I just get
called a proselyte for having adopted XSLT and being preachy about
it. I do know that I've been called in after the fact to clean up
their messes when they make 11th hour changes to their Java or C++
that mess up things like Unicode encodings or markup
constraints. The "oh, I didn't think about that", or "oh, I didn't
know about that" are weak defensive arguments when they originally
claimed they didn't need XSLT because they could do everything they
needed in the ______ language. I don't have to think about it
because XSLT and XQuery are built by and for XML.
I hope this helps. I think you'll find it an uphill battle, but the
battle won will be a big benefit to your company and not just in
report writing.
. . . . . . . . . . Ken
At 2011-10-13 15:50 +0100, Vasu Chakkera wrote:
Guys,
I am in a situation where I am having to advocate that xsl:fo is
great( what a pity!!) .. Some one came up with jaspersoft (
http://www.jaspersoft.com/ ) and is hell bent on thinking that XSLT is
error prone ( I guess they come from a hard core c++, c background)
and they do not think that XSLT is a great Idea. I tried to reason
with my colleagues that if XSLT were error prone, most publishing
companies will go crashing down and most Banks will go out of
business. These guys agree , but there are some business decision
makers who believe that XSLT is a no no .. I have made a document
listing the sooper gud things ... but need to know... has anyone tried
this jaspersoft thing and is there any points I can get from peoples
experiences on why we should go to Jaspersoft and not do XSL:FO.. I am
trying to get some points that i can add to my advocacy document.
Vasu
--
Contact us for world-wide XML consulting and instructor-led training
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
G. Ken Holman mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers: http://www.CraneSoftwrights.com/legal