XSL Tools Requirements
What should the initial requirements be for XSL Tools 1.0 release. Note that not all ideas will necessarily make it into the first release. Please use this page to make your suggestions as well as enter an enhancement request in the Web Tools Incubator component. If you do make a bug/enhancment request, please put the bug number here and link to it as well.
The overall release plan can be found on the XSL Release Plan page.
XSL Tool Features Requests
- bug 215120 Launching should be able to run either a simple pipeline or a more complex pipeline using XProc as the configuration language. An yac is an example of an xproc processor.
- Possibly have pre-existing Launch configurations that can be modified for Docbook, Dita, and Schematron launching.
- 0.5M4 - Allow for the launching of externally defined XSLT processors. This should be user configurable. This would be an alternative to the ones provided by providers through extension points.
- DS this is already done
- bug 213855 - XSLT Launching should not depend on JDT being installed. This is so that other tooling projects like PDT, Ruby etc could include the XSLT support if necessary with out having to include JDT.
- bug 214228 - Launching should be dependent on the Content-Type not by specific extensions. Currently it looks only for *.xml files.
- bug 214235 - Ability to view the Nodes that are in a result set/node set.
- DC - 2008-01-03 - Currently all variables whether they are strings or nodes, all display the same in the variables view. Need to allow Node Expansion of Node result sets, and display strings as variables.
- DC - 2008-01-03 - Also should be able to view the current node that a template is acting on either in the variables view or as a seperate view.
- bug 215119 Ability to put break points in both the source xslt as well as the xml input file.
- 0.5M4 - Ability to put break points in any stylesheet that is included or imported, and have it stop at the break point.
- DS 2008-01-06 - you can put breakpoints on any included stylesheet
- 0.5M4 - See all variables that are currently in scope for the xslt being debugged.
- 2008-01-03 - Basic functionality implemented.
- 0.5M4 - bug 213850 Ability to set the XML Input before Debugging begins, if launched from Debug As-> and no existing launch configuration has been created.
- DS 2008-01-09 - Done
- DC 2008-01-12 - Assigned bug 213850 for verification and tagged for M1.
- DS 2008-01-09 - Done
- 0.5M4 - bug 213766 Make sure line and column numbers are displaying in the xml editor when in debug mode.
- DC 2008-01-03 - Tested with current branch. This is working correctly. Line numbers and column numbers are displaying.
- bug 214236 A view to see what the current Result Document would look like, and what it looks like at the end of a transformation.
- If transforming to HTML or XHTML, allow preview of the currently debugging result in a Browser view.
- DS - 2008-01-06 - At the end of the transformation, an editor is opened on the result document. Could flush file buffer if hit a breakpoint half way through and this should show the current result document in the editor itself.
- DC - 2008-01-12 - assigned and added keyword plan.
- 0.5M4 (partially) - bug 215118 Ability to step between Java and XSL in the debugging process. This is useful for tools like Dita-OT that use both Java and XSLT in their build process.
- DS 2008-01-09 - It is now possible to add breakpoints in called Java code, but the transition between XSLT and Java stepping is not done yet.
- 0.5M4 bug 213853 XSLT Preferences should reside under the Web and XML -> XML preferences section.
- 0.5M4 bug 215128,
bug 195028, bug 213852, bug 213854- Content Assitance for all XSL elements that are in the namespace. It would also be nice to have content assistance automatically for any other namespaces that are known.
- DC - Some of this is already possible through the use of XML Catalog contributions, as the XML Editor will pickup
any grammars that it finds and knows about in the XML Catalog that are in the source document.
DC - 2008-01-12 - Initial implementation only supports XSLT 1.0 as it uses the XML Catalog Contribution point. Future versions will either use an extension point from the WST.XML to allow grammar contributions, or may use a custom resolver to provide the resolution for the grammar.
- DC - 2008-01-18 - Custom resolver has been written to use to determin which version of xslt is being loaded and which version of the xsd grammar for xslt to use for content assist and structural validation.
- bug 201954 - XPath creation, editing, and testing support.
- bug 213775 - Configurable syntax highlighting for XSL. Allow differentiation between XSL elements and those not part of the XSL transformation namespace.
- XPath support should have content assistances for select, match, and test attributes. This should provide AXIS as well as XPath function expressioin support. Along with any appropriate documentation for each of the functions.
- Templates - we should provide a list of commonly used XSL templates both for new files and for attributes and elements.
- Variable content assistance - When referencing a variable or parameter, we should provide content assistance for any variables or parameters that are in scope.
- If a variable or paramater is unknown, CTRL-1 should provide available suggestions.
- Make sure any compilation errors are highlighted with red squiggleys. Color of squiggleys should change depending on the severity of the error. Yellow for warning, red for error.
- Provide template support for Call-Templates. If creating/defining/calling a named template, content assistance should be availble for the name attribute, providing a list of suggested names either have no template defined, or already have a template defined depending on the location where content assist was invoked.
- Validation should not necessarily occur on all grammars in the XSLT, as this could lead to false errors, as XSLT templates will be inserted into elements that may not be expecting them. This is not an error itself.
- Provide a view with the availability of all XPath functions or nodes that could be used at that particular point. Drag and Drop support would be nice to be added to the editor.
- Possibly create just a Source editor for XSLT, as the existing Design view doesn't necessarily work well for XSLT development. Or create a new design view that allows graphical creation of an XSLT based on existing grammars or an existing XML instance.
- Provide out of the box support for XSL templates for DITA, DocBook, and SchemaTron.
- Include optional project creation for DocBook and DITA Eclipse Help System documentation. The Eclipse Help System option should create a plug-in.
- Include optional project creation for Eclipse Corner Articles. The Eclipse Corner Articles should create a project that builds HTML pages from DocBook or DITA source. It would be nice for this option to be extensible by adopters so other publications like DeveloperWorks, which already supports XML + XSLT for authoring, can make use of the new project creation wizard.
- Provide basic refactoring support.
- Content Assistance for stylesheets that are include or imported. The parent stylesheet should be able to see variables, call-templates, with-params, etc from these imported and included stylesheets.
- The ability to specify what should be validated and what shouldn't be validated.
- Batch Validation of XSLTs in a directory.
- How are XSLT's validated that may depend on external URI sources?
- context sensitive help (info pops)
- task-oriented help information (available from help browser)
- Articles or on-line tutorials on getting-started and how-to-use.
- Document some use-case scenarios that could be used (by others) for brief smoke test.
- Automate build and download pages.
- Add automatic JUnit tests.
- bug 212934 Use Xalan bundle (e.g. from Orbit) instead of raw jar in org.eclipse.wst.xsl.xalan.
- DC - 2008-01-12 - Xalan 2.7.0. and all dependencies org.apache.bcel v5.2 and java_cup.runtime 0.10 are now in cvs in orbit.
- bug 215121 Externalize Strings (I recommend we "get started" with making a pass on basics, then try and "keep up" when ever coded is added or modified).