When will you merge?

Asked Laurent Montel me in private mail, referring to when Patternist, the XQuery/XPath/XSL-T implementation, will be proposed for merge into kdelibs.

Personally, I still want to wait a bit longer. I don’t know about Vincent Ricard, the other Patternist developer. The reason is that two XQuery features remains, XML literals & path expressions, which can be a bit invasive to implement and also heavily affect the user experience. On the other hand, once those two are implemented, XQuery is essentially finished.

What is Patternist anyway?

I see Patternist more of a framework than a particular language implementation. The second generation of XSL-T and XPath are intentionally close to XQuery,[1] and this has as effect that there are no strong borders in Patternist for these languages. For example, XSL-T will be established as a different front-end, plugged in the same place as the current joint XQuery/XPath tokenizer, but still feeding tokens to the same Bison parser.

That these languages are formed in a family has many positive effects, as one might imagine. It allows heavy reductions in implementation complexity and the possibility to centralize efforts. For example, the optimizations implemented for XQuery(if one chooses to see it that way) will also work out of the box for XSL-T, because the same AST is used.

The end point is that Patternist has as mission to satisfy KDE’s needs for conformant, practical and efficient XQuery, XSL-T and XPath support.

Completeness a side — from an engineering perspective it surely has its merits to merge earlier. It would allow one to get familiar with problems earlier rather than later, and it would mean an incremental approach instead of the “Let’s drop a bomb”-method. I’m unsure, perhaps we’ll just wait Until It’s Ready, or perhaps a more earth-bound approach would be a realistic choice. Suggestions and expressions of preferences are welcome.

1.
In fact, XPath is a subset of XQuery, and the two specifications are generated from the same source. It is also difficult at best to find scenarios that XQuery can solve that XSL-T cannot solve and vice versa(although they nevertheless clearly excel at different things).