\usepackage{savesym}
\savesymbol{todo} % occurs in both packages
\usepackage[show]{ed}
\restoresymbol{ed}{todo} % now available as \edtodo
\usepackage{todonotes}

• KiWi’s strength as a scalable and extensible platform for social software (not just as a semantic wiki!) is its architecture. Based on EJB3 and Seam, it has an incredibly steep learning curve – EJB was one of the topics that I tried best to avoid when studying, now I regret that; on the other hand it also took the people at Salzburg Research several months to come up with that elaborate architecture.
• Openness attracts the community: The KiWis decided to open their programming camp to external developers, as a first effort to start community-building.  They were really committed also to teaching me, the visitor, how to use their system (thanks, Mihai, Rolf, Sebastian, Stephanie, Szaby, Thomas – and their colleagues from Aalborg, Brno and Munich as well!). Even before the programming camp, they did not jealously lock away their sources, but gave external interested people access.  And now, with further adoption of the software in mind, they are switching to the most liberal license, i.e. BSD.
• With our Subversion and Trac infrastructure, we have done great steps towards more productive development. Still, the KiWis leverage more professional tools, which really make life easier. OK, they are not open source, but require considerably less hacking in order to make them productive: Jira (bug tracker), Fisheye (repository browser), Crucible (code review system, not yet used), and Hudson (automated integration tester).

“KiWi knows” what else I will be able to report in the near future – stay tuned!

I should have known earlier. I knew it earlier! This paper already existed in my document collection, added on 2007/08/08, and in my ever-growing to-do list there was a neglected entry “read documents added on 2007/08/08”!

For a moment it seemed to me that I had reinvented the wheel, but actually it’s not that bad. While XSDL has a solid formal specification (which Krextor does not have), it seems that it has never been implemented. Krextor has been implemented, as it emerged from a very concrete need to get a concrete task done, and it has been evaluated in various settings. Therefore, I can use XSDL as an inspiration w.r.t. the theoretical background and a nicer declarative syntax.

• pattern matching on XML elements and attributes, using a syntax that is close to literal XML or to XPath (for easily writing extraction rules, which should also be done by other developers in future)
• functional programming (in some way), as the whole idea of mapping XML to RDF (and thus XML nodes to URIs) can be modeled most elegantly using a functional approach. (This is rather a requirement for me implementing the generic core of Krextor, but also for extraction module developers once the XML input language is a bit more complex.)

Having looked a bit into XQuery, Scala, and JavaScript (and a little bit into Haskell), I decided to stick to XSLT for now. Functional programming is awkward but possible, and XML pattern matching is awkward or non-intuitive in most other languages.

Below you find three groups of mathematician that most likely need different amount of arguments to be convinced (please note that I am not citing Cris. I simply present what I remember from our discussion and made up the names of the groups):

• Pen-and-Paper guys: They only use computers for publishing but all mathematics is actual developed on paper. The publishing process is seen as a tedious and inconvenient activity that takes time away from the actual job that a mathematicians wants to do. The digitalization is annoying (proof reading). In earlier times, this was done by secretaries and the publisher, but nowadays publishers only accept LaTeX, which is really seen as a burden by this group of mathematician.
• LaTeX Lovers: There are mathematicians that think in LaTeX. The use it a lot for developing their ideas and incrementally revising proofs with colleagues. This groups seems to have an increasing influence on scientific publishing as most publisher (in mathematics) will nowadays reject a submission if it is not provided in LaTeX.
• Innovators: The third group wants even more. (We didn’t really talk about this group long) For example, this groups promotes semantic technologies and aims at making mathematics machine-processable as well as bringing mathematics to the web. I assume that includes vast parts of the MKM community.

Maybe we need to start asking ourselves: Would we use our tools and services? (Who is using sTeX?) And if so, for which activities? Think of the very early steps towards a new topic. Would you like to be forced to content mark-up? Although we provide full flexibility in switching between concepts, simply having to establish theories and marking up structure really slows down the creative thinking. So when is a good timing of using content-based techniques? Do we restrict it to the very last stage of scientific work, i.e. the publishing process, or teaching (the latter not even recognized as scientific activity)?

I am collecting arguments on gains and burdens of content mark-up (in the panta rhei trac), in particular, with a focus on the technologies and services provided by KWARC. I’d appreciate your feedback and comments!

It turned out that XSLTdoc is a really nice solution for that: Just put a few additional XML elements in front of every template or function and run a special XSLT to generate the documentation. Works like javadoc and looks nice.