Towards EXSLT "1.0"

For a backgrounder on EXSLT, see my article "EXSLT by example". EXSLT was born of general contribution of the community on the XSL mailing list. Jim Fuller, Dave Pawson and Jeni Tennison started off a private thread to turn the list discussion into action, and I soon joined them. The result was the exslt web site, mailing list and initial set of extension specifications. We all agree that Jeni put the most work into it, and is the leading light of EXSLT, but she has been very busy lately (genius tends to occupy itself in overwhelming volume), and the rest of us have also had a hard time giving EXSLT the effort it desires. Last week, however, Jim Fuller and I decided to take some steps towards getting EXSLT back on course. In part, this is because some people want to get things moving on EXSLT for XSLT 2.0.

Here is a list of the things we're considering taking on in order to get to something we can call "EXSLT 1.0".

Clearing up licensing

I have proposed switching from the intended (but unstated) public domain to a CC attribution license for all EXSLT work products. It seems everyone accepts this, but the main remaining question is assignment of copyright. Some of the suggestions:

  • Assign to all the four managers. But do copyright decisions then have to be unanimous amongst us? Is it a problem that we reside in different countries?
  • Assign to Jeni Tennison alone. But does she have the bandwidth to dispatch all copyright matters?
  • Assign to the EXSLT.org domain. I can't now find who suggested this to me, but my main question is the legality of such a move.

Creating some caretaker foundation for EXSLT is not really an option, because no one (I think) has time for all the work that entails.

Improving the information content of the EXSLT Web site

We need a good overview. We need news that we can keep up to date without too much effort, including references to the many good articles on EXSLT. We need better documentation for almost all modules (the perennial example is that users get confused as to whether or not they have to download stuff from EXSLT.org in order to use the extensions). We need a better way to manage information about implementations. We need a FAQ. We should address outdated URLs from EXSLT specs (e.g. http://lists.fourthought.com/pipermail/exslt/2005-January/002169.html).

>

We also need to think about the confusion between the namespaces URLs used in EXSLT. The extension URIs are different from the specification URLs. I understand how this distinction came about, but I think it has proven too confusing in practice. I suggest that we should put a RDDL gloss at all the namespace URL end locations, including a summary of the extension module and a pointer to the specifications.

Packaging EXSLT

We need to provide a package we can call "EXSLT 1.0". Something clear, recognizable and ready for download. It should include at least documentation on modules that proved useful over time. We should update the reference stylesheet implementations and examples (see e.g. http://lists.fourthought.com/pipermail/exslt/2005-February/002174.html).

>

There have also been suggestions and proposals for new modules on the list, including:

My feeling is that we should go to 1.0 with the stuff that's already established on the site. We can add modules for a 1.1. release.

And then we would set up for EXSLT 2.0 extensions, which I understand people are itching to seed (I'll probably watch from the side lines as I work through my overall opinions on XSLT 2.0).

Jim has promised to jump-start all these tasks. I'll keep folks posted.

I welcome comments on this topic here on Copia, but if you really want to help, or want to engage in discussion with the overall community, please do join the mailing list and chip in.

[Uche Ogbuji]

via Copia