SomedayMaybe

At present there is no simple way to debug XQuerys running in eXist.

Debug capabilities need to be provided to support facilities such as: breakpoints, watches, local variables, stack traces and execution control (step-in, step-out, step-over, run to cursor).

It seems that each IDE or tool has its own API for debugging and as such a plugin for each must be developed. eXist may typically run in one of two modes - embedded or server.

When eXist is running as a server a protocol is needed to talk between the IDE plugin and the eXist server, this protocol should be the same for all the plugins and it would be prudent to use a known existing open protocol such as JDWP or DBGP. Whichever protocol we choose it must be able to support the debugging facilities of all the IDE's. Only as a last resort if the other options are considered unsuitable should we then consider developing our own debug protocol.

When eXist is running embedded the same protocol API could be used in-memory to communicate between the plugin and eXist.

oXygen

oXygen XML Editor provides an XQuery debugger that supports a number of popular XQuery processors such as Saxon. it would be advantageous to be able to use this with eXist.

Eclipse IDE

XQuery Development Tools is an effort to try and integrate XQuery development into Eclipse. It makes use of its own custom protocol.

There is also the XQuery Development Tools in the Eclipse Web Tools Incubator, that could be used.

The XSL Tools incubator at Eclipse, could be used to see how to hook into the Eclipse Debug framework, and possibly make it extensible.

Other

This attempt at a specification for a debugging protocol could also be of interest - http://www.xdebug.org/docs-dbgp.php This debugging protocol has already an eclipse client with DLTK (dynamic language toolkit: http://www.eclipse.org/dltk/).

A method to analyze an XQuery at compile time for the dependencies on objects in the query. If parts of the query could be described in a dependency tree, rather than the query being executed in a linear fashion we could do some out-of-step parallel execution of the query and then recombine the results for delivery.

By default, eXist creates its data directory in EXIST_HOME/webapp/WEB-INF/data. On windows, this means that the data dir is located below the Program Files directory. While this is usually ok for Unix (Apple?) users, Vista doesn't really like it when users are writing data into Program Files (it creates a shadow dir if you are not an administrator).

The installer should ask for an alternate location for the data directory, maybe depending on the OS type.

The distinct-values function could use existing range indexes.

The backup utility should also include a copy of the relevant server configuration files (mainly conf.xml) into the created backup. Settings like page size, additional XQuery or index modules etc. are important.

eXist already provides a util:catch() function which basically corresponds to a Java try-catch.

The XQuery 1.1 draft also defines try-catch, but more closely integrated with XQuery. It should not be too difficult to implement this in eXist.

See http://www.zorba-xquery.com/doc/zorba-0.9.2/zorba/html/trycatch.html for some examples.

eXist's XQuery Update Extensions were implemented before the first W3C drafts were published.

The differences between the W3C recommendation and our implementation are not that big, though there are some subtle differences concerning the processing model. In fact, the recommendation simplifies a few issues.

http://www.w3.org/TR/xquery-update-10/

People often use the collection hierarchy to encode information, e.g. /db/year/month. Now, imagine you need to search all collections corresponding to the years 2001 to 2003. If the year isn't encoded in the XML docs as well, you need to use the path information. For example:

This works, but is not very convenient. It would thus be nice to have an extension function which behaves like fncollection, but accepts a regular expression against which the collection paths are matched.

The benchmark tests (in test/src/org/exist/performance) could be a good basis for continuous performance and regression tests. However, running them through Ant is maybe not the best solution. It would be better to have a small GUI. Users should be able to load a test file (see test/src/org/exist/performance/test.xml and execute the tests defined in it.

This could also encourage users to add their own test cases. We still lack good test data that can be redistributed.