Very much agree with Dimitre and Wendell here: move production work to XSLT 2.0
in general, start to experiment with XSLT 3.0 capability where you really need
the streaming support.
Michael Kay
Saxonica
On 27 May 2014, at 18:26, Vasudev Kandhadai
vasu(_dot_)kandhadai(_at_)gmail(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Dear All,
After a lot of convincing , the architectural team finally agreed to approve
Saxon9.5. There is a bit of a relief, but I am having to make a decision on
whether we upgrade from XSLT1.0 to XSLT3.0 directly? The code base is not
very big and we are OK to rewrite to adapt to better coding practices that
come with XSLT2 and 3.
I am assuming that the coding paradigm is slightly different in XSLT3.. The
approach on how to write templates, the restrictive xpaths etc , could be
backwards incompatible etc..
I need advice on this/ Is it true that the coding approach is different using
the XSLT3 ? I am fairly confident that the XSLT2 is a good point to start.
The only reason XSLT3 was even in the discussion was because of the HUGE xml
files. Currently we run a Sax Java splitter over the big XMLs and run XSLT1
files over the smaller chunks. This works well. My options with XSLT2 would
be to change the XSLT1 to XSLT2 and keep remaining things same..
With XSLT3, we may consider removing the SAX splitters, as it may no longer
be used. XSLT3 will probably take care of the memory issues with HUge XML
files.
Putting all my thoughts in,, Hopefully will get some clarity with the expert
advices from you all..
Kandha
XSL-List info and archive
EasyUnsubscribe (by email)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--