This page acts as a register of suggestions or ideas for future enhancements to Saxon, or notes of current restrictions. There is no implication that any of these will ever be implemented, although any developer who wants to take any of them on is welcome to contact me.
To add your own suggestions to the list, email Michael Kay. Ideas will only be added if I consider the enhancement desirable, and even then there is no promise of action.
| Number | Enhancement | Status |
| 1 | Norm Walsh suggests that as the Saxon transform operates as a SAX2 filter, any user-supplied entity resolver ought to be used to resolve the URIs in (for example) the document() function, or xsl:include and xsl:import | Superseded by JAXP URIResolver |
| 2 | As the Saxon transform operates as a SAX2 filter, any user-supplied SAX error handler ought to be notified of errors occurring during the transformation | Superseded by JAXP ErrorListener |
| 3 | An output writer supplied to receive output of the transformation ought to be closed by the user, not by Saxon. | I think this is OK in Saxon 6.1 |
| 4 | Implement JavaScript extension functions | Not urgent |
| 5 | Implement a COM interface | Requested by a number of users. |
| 6 | Change xsl:document to generate the output file relative to the base URI rather than the current directory. | Will follow XSLT 1.1 |
| 7 | Provide extension functions to invoke regular expressions. | Not urgent. |
| 8 | Restriction: if the same document is kept in memory, and several transforms are applied using it as input, there may be conflicts if the space-stripping rules in the different stylesheets are incompatible. | Some improvements in Saxon 6.3. |
| 9 | Implement a richer set of international collating and numbering rules | Not urgent. Some progress made on numbering. |
| 10 | Add an extension that allows creation of entity declarations in the internal DTD subset of the result document (the specific request was for unparsed entity declarations). | Done, saxon:doctype. |
| 11 | Implement, and invoke, the JAXP javax.xml.parsers interfaces to obtain a SAX parser | Done in Saxon 6.3 |
| 12 | Allow an extension element to be implemented by a named template, so that instead of lots of xsl:with-param elements you can specify parameters as name="value" attributes. | Not urgent. |
| 13 | Fit the Java-only Saxon API into the JAXP framework, that is, make the assembled collection of rules a Templates object from which a Transformer can be generated. | Considering it. |
| 14 | Make the PreparedStyleSheet object, and everything it owns, serializable. This gives benefits in an Enterprise JavaBeans environment. | Useful, but too much effort, difficult to test. |
| 15 | Provide a SAX filter to do XInclude processing, and allow this to be run between the parsing and transformation stages. | Anyone prepared to do it? |
| 16 | Replace saxon:preview with a SAX filter that does document splitting, applying a transformation to each subtree of the split document, and possibly another filter to optionally merge the result trees of these transformations. | Not urgent. |
Michael H. Kay
3 May 2001