>No Docbook Stylesheet Plugin.
To be more precise, the Docbook Stylesheets and their supporting Xalan java extensions didn’t make it through Eclipse IP review. So unfortunately, this puts a partial damper on the requests we’ve had for some integrated support for Docbook in the XSL Tooling project.
However, I don’t think all is lost, as with other projects, one can still download and use the stylesheets with the XSL support we provide. It just means you’ll have to work a bit harder, and I’ll have to become more creative on designing an example project.
I do plan on updating Chris’s authoring article he wrote a while ago, so that it leverages the XSL Tooling project instead of old EclipseXSLT project. EclipseXSLT was one of the code bases that was used to start the XSL Tooling project, much of that code base has been rewritten since that initial contribution, but the same concepts still apply. So maybe I’ll do that on my plane trip out to California next month.
My question for the Docbook users are, do you want the XML Schemas for Docbook to be included in the XML Catalog so that editing and content assistance support is available out of the box? If so, what versions do you want: 4.5 or 5.0?
For DITA, I think we can get the DITA open toolkit as an optional plugin configuration, but I’m not overly familiar with DITA or the open toolkit. So what would you need for us to support in the way of XSL support? Is there a standard set of DTDs or schemas for DITA? What do you want supported? Report your requirements here or in bugzilla.
XSL Validation Settings.
I’ve used many different XSL editing tools over the years. One of the items that has always puzzled me is that all of these tools lacked support for configurable Validation setting reporting. It’s not uncommon to have XSL stylesheets that aren’t completely runnable and pass validation by themselves. Many of these smaller stylesheets are included or imported into other styelsheets, and the whole is a valid stylesheet. With the latest release of XSL Tooling a user can now control the validation error reporting level for many pieces of the XSL validation.
This is great, for getting rid of extraneous Error messages, that other XSL editing tools don’t allow you to control. You can thank my fellow committer, Doug Satchwell, for his tireless effort on working on this validation scenario and configuration. Currently the above is workspace wide, however, Jesper Moeller has volunteered to try and get the project specific settings implemented as well.
XPath Content Assistance.
I didn’t make as much progress on this as I had hoped. Mainly because I got caught in the standard architects dreaded trap. That of trying to over architect the current problem, and looking to far ahead. Eventually, I’m going to need an XPath model, to offer some of the functionality I would like to offer, but for now, I don’t think I need it. So, to fix some of the problems with content assistance for XPath, I’m going back to the basics and start over. Mainly to fix the issues and design choices that I had originally made when learning to implement it, but also to hopefully provide a better implementation for content assistance going forward. Hopefully, I can get that worked out for 0.5M8 next month.
XSL Tooling is moving right along, and the editor has advanced far enough along that for most my XSL editing needs, I have migrated to it. Where we are still lacking a bit is in the Debug support. Hopefully we can give that a bit more attention in the coming months.
As always, we are looking for community feedback, if there is something missing or not working please let us know.