Pipeline Gui Windows questions considering integration development & user

Hi, Question: 1. About Integrating apps into pipeline I started integrate (develope) our dtbook 2.02 - xsl 1.0 java batch application (jdk 1.6) into latest pipeline gui for windows. The application is using xsl 1.0 (xalan, xerces, exslt) to dtbook into special text files. All another is working well in our pipeline script, but not xsl 1.0 transformations. I have tryed load different jar libraries under run time, but without success. Xsl 2.0 is possible come in a question later, if there is possible to extend xsl 2.0 with Java too. (Now I have done the same with xsl 1.0 xalan.) To get it work, which development direction I should take and why (performance, work load etc.). Which is the most easiest or most slightly work to do? Do you have some documentation links to read? Possible options?: - our application as service for the pipeline gui (an example?) - integrade into Pipeline as Exciple plugin, or extension point? - If a direct integration opton, then there is Important to have own classpath for our jar framework to load, until xsl 1.0 is used! - another? 2. How accessibility is yours Pipeline Gui for Windows for visually impaired users? Is there some configurations, documentations exists before users can start to use it? What I have understud, there is good possibilties for it. (I have read IBM SWT article about Eclipse RCP and accessibility.) 3. Can you tell somehting your future development directions with pipeline, gui / service? Thanks in advance, Tuomas

Dear Tuomas, 1. Integrating

Dear Tuomas, 1. Integrating XSLT-based transformations It should be fairly straightforward to integrate an XSLT-based conversion as a Pipeline transformer. The Pipeline has built-in functionality to even create such transformer without writing Java code. You can find more information on the Pipeline developer documentation: http://daisymfc.sourceforge.net/doc/developer/transformer-authoring-guid... http://daisymfc.sourceforge.net/doc/index-developer.html Note that the Pipeline uses Michel Kay's Saxon to run XSLT transformations. Saxon is an XSLT 2.0 and XPath 2.0 implementation but is also able to execute most XSLT 1.0 stylesheets. For an example of a pure XSLT transformer, see the se_tpb_dtbook2latex (using XSLT 2.0) http://daisymfc.svn.sourceforge.net/viewvc/daisymfc/trunk/dmfc/transform... Or the dk_dbb_dtbook2rtf transformer (using XSLT 1.0) http://daisymfc.svn.sourceforge.net/viewvc/daisymfc/trunk/dmfc/transform... Finally, note that you do not have to develop an Eclipse plugin or write an extension point to create a new Pipeline transformer. These concepts belong to the Eclipse RCP framework which is only used for the GUI layer of the Pipeline application. 2. Pipeline accessibility Yes the Pipeline GUI should be out-of-the-box accessible to visually impaired users on Windows, Linux and Mac OS X. The underlying Eclipse RCP and SWT libraries are using the IAccessible2 API to call the native accessibility layers. See also the Pipeline FAQ section on accessibility: http://daisymfc.sourceforge.net/faq.html#access 3. Further developments The Pipeline project is now in maintenance mode. It means that the DAISY Consortium will not allocate new resources to further develop it, but will however keep on supporting and helping third-party contributors. As for future directions, we're about to officially launch the Pipeline 2 project, which is a fundamental redesign of the Pipeline framework to embrace new technologies and standards (notably W3C's XProc) and better integrate with the DAISY community and publishing mainstream. You'll find more information on the Pipeline 2 development site: http://code.google.com/p/daisy-pipeline/ http://code.google.com/p/daisy-pipeline/wiki/ProjectCharter HTH, Romain.

1. A reason to use xsl 1.0

1. A reason to use xsl 1.0 with Java extension is that our application needs java for better data handling and some xsl functions to comparing node-sets or nodes to each another. Clean xsl scripts are not enougth to it. But I will look after scripts you mentioned any way, if there is some way. I know that I do'nt need to develop any plug-ins or end-points, but my idea was - in this special case - that after developing like those, I would to execute our application in own different classpath and class loading. In that case, pipeline framework or script should call our code as usual, but have different, own set of xalan etc parsers and frameworks than pipeline has. Is that possible to done? Perhaps it should work as a pipeline service enstead. Thanks for good answer! And about links also. Tuomas

The implementation used for

The implementation used for XML parsing and transformations are configured with the regular JAXP factory properties, in the pipeline.properties fle (notably javax.xml.transform.TransformerFactory, javax.xml.parsers.SAXParserFactory, and javax.xml.stream.XMLInputFactory). If you want to use other factories in your transformer you can always temporarily set these system properties to something else at the beginning of the execution, then reset the old values after the execution. If you use the built-in XSLTRunner tranformer, you can also set the transformer factory using the "factory" transformer parameter. See how it's done in one of the two aforementioned transformers. HTH, Romain.

Copyright © 2012 The DAISY Consortium, Some Rights Reserved.
Creative Commons License: No Derivative Works
Creative Commons

Valid XHTML 1.0!