OK, I think it's time to finally improve XUL templates. There have been numerous proposals out there about how to to do it, but no one can really agree on what the best approach is. There is generally consensus that there needs to be support for XML data as well as RDF, and/or other data formats. What there isn't consensus on is what the templates will look like and whether to use a different template mechanism for different kinds of data. Unfortunately, like most of Mozilla, no one is in charge of things, so while lots of ideas float around, nothing actually gets done.
There have been a number of suggestions to use XSLT for XML data. Sean McMurray has proposed and implemented a simple scheme for this, that is to transform XML using XSLT for display in a XUL interface. It's so simple in fact, that it could just be used as is, after a bit of work to clean up the design and code. There are some advantages of using XSLT over other proposals, but after much thinking I don't believe it will turn out to be very feasible solution. Despite being a "standard" and having sufficient documentation available, I'd imagine XSLT wouldn't be any easier to understand than the existing XUL template mechanism, apart from learning RDF, which wouldn't apply to a XML data template anyway. Perhaps it's just the namespaces and the XPath that make it look complicated. However, adding a simple and automatic XSLT feature as Sean proposed would be useful to have available in addition to a proper template system.
So what am I planning on doing? Well, first I'm working on Yet Another Template Proposal. Why might this proposal be better than all the others? For one, this one is primarily based on the other proposals, namely those made by the Mozilla template and RDF regulars on the Mozilla wiki. Also, instead of some grandiose plan to rewrite the templating system to do everything anyone would want, it will instead involve incremental changes to the existing template system. The idea is to change small bits at a time, adding features as necessary. If we find that one idea didn't work out too well we can change it without much fuss.
The eventual goal and syntax I have in mind would have some things in common with the existing syntax -- in fact, for RDF it should be completely backwards compatible. But for other types of data, or indeed even for RDF if desired, the syntax is similar to be easier to understand and allow more shared implementation, yet different enough that, for example, it shouldn't bog down the XML handling with some requirement for the RDF handling. Just as important, it should be relatively simple to implement in the existing template builder code without drastic rearchitecting.
Do I think my new proposal will be perfect? Of course not. But one big advantage is that I plan to actually implement it, as opposed to most of the other proposals which won't be. I'm hoping that by implementing it incremently we can see better templates sooner rather than later. In fact, I've already implemented one new feature for RDF based generation which will appear in the Linspire version of Nvu.
More when I've got more specifics...