I first came across XSLT when writing about the ancient Japanese game of Chu Shogi. I had decided to use DocBook to write the text, and I quickly converted from SGML + DSSSL to XML + DSSSL, and later, XSLT.

Subsequently, in 1999, I got a job as a C++/XSLT/Javascript developer with Knowledge Support Systems, where I was the company expert on XSLT (1.0, of course). It was here too, whilst on a C++ training course [yawn], that I first learned about Eiffel.

When leaving that job, I determined to experiment in a parallel implementation of XSLT using Glasgow Parallel Haskell. However, the Haskell XML parser at the time was not namespace-aware. After spending some time trying to upgrade it, I abandoned Haskell in favour of Eiffel.

Much later, in 2003, I was working for Brenton Safety, a Californian company, as a result of an open source project I had written in Eiffel - EDOM (Eiffel DOM). This was an Eiffel wrapper around the Xerces C++ DOM, to which I added a wrapper around Xalan C++.

When Brenton Safety went bust, I had to look for a new job. But I was anxious to sharpen my Eiffel skills whilst searching. So I contected Eric Bezault, leader of the Gobo project, to see what I could contribute. Eric said he had long wanted an XSLT processor, written purely in Eiffel, in order to generate html pages from the Gobo documentation (written in a DocBook-inspired dialect of XML with special knowledge for formatting Eiffel syntax). It had to be pure Eiffel, not a wrapper around another program, like EDOM was, so that users of Gobo did not need to install anything other than an Eiffel compiler (nowadays it doesn't even require that, as Eric has written gec, the Gobo Eiffel Compiler).

Given these requirements, only a subset of XSLT 1.0 needed to be implemented. Since, on the rare occaisions when I still used XSLT, I would use xsltproc for my processor, due to its famed speed (I wasn't aware of its non-compliance at the time), and being already installed on my Linux system. As I didn't have any idea on how to start writing an XSLT processor, I took a look at the documention for xsltproc. When I was reading it, I saw that Daniel Veillard had refered to a paper written by Michael Kay about the design of Saxon. Daniel said he wished he had read this paper before designing xsltproc.

As I was already familiar with Michael Kay's writing (I owned a copy of the second edition of his XSLT Programmers' reference), I had no hesitation in reading the paper for myself. When I did so, I was so impressed (I can't remember now by what) that I determined to use a similar architecture for gexslt (Gobo Eiffel XSLT). My one concern was that the paper was referring to an XSLT 2.0 processor. Now I knew that XSLT 2.0 was still in the design stage. Would the paper still be relevant to an XSLT 1.0 processor? The obvious thing to do was to email Michael himself. Michael replied that there wasn't much specific to XSLT 2.0 in the paper, and also that XSLT 2.0 was reasonably well developed (this was December 2003, so my memory is somewhat hazy - I ought to dig out the email).

So, should I go for XSLT 2.0 or not? I raised the question on the Gobo developers' list. After a short debate (XSLT 2.0 is HUGE!), we decided we didn't have to implement everything at once, but we might as well go for it. Gexslt was born. I spent the rest of December reading and digesting the working drafts.

From the start the intended structure was a library which Eiffel programmers could use to invoke XSLT from their applications, and a command-line processor as a stand-alone XSLT 2.0 interpreter. The latter was to be named gexslt (in line with the other Gobo tools, geant, gexace, gelint etc.). A problem soon arose. How to incorporate support for http and ftp URI schemes into the library? An XSLT interpreter without support for http URIs is not inconceivable, but would be very strange. But Gobo code had to be portable across all Eiffel compilers, and the only portable library in existence with socket support was e-POSIX, which depends upon Gobo!

The solution adopted was two-fold. Firstly, I implemented support for OASIS XML Catalogs within the Gobo XML library. But more importantly, it was decided that there would be two versions of gexslt - one internal to Gobo (for reasons stated above), and another one that would incorporate features depending upon support from other libraries (such as e-POSIX). There were very few architectural implications for this decision.

In September 2004, gexslt had progressed to the point where it could run an identity transformation. Shortly afterwards, I decided to start my own sourceforge project to begin implementation of the external version. But first I had to find a name. The obvious candidate that sprang to my mind was gexslt2. But I didn't like this, because it implied that gexslt was obsolescent. So I tried to think of a word that could be pronounced similar to the appearance of gexslt (I pronounce it gee-ee-ecks-ess-ell-tee). The only word I could come up with was gestalt. But when I looked it up in my German dictionary, I thought it was the perfect name for a transformer!

Now gestalt adds support for http and ftp URI schemes for fn:doc() and fn:document() (maybe fn:collection() to come?), and support for http, ftp and mailto URI schemes for xsl:result-document.
Probably https support will be added at some time. And I have more exotic ideas too.

Since the W3C have decided to kill the notion of standards from their vocabulary (proposed recommendation for XML 1.0 "Fifth edition"), I have abandoned the project.