Lars Trieloff's Collaboration Weblog

The World Wide Web Consortium has released new working drafts concerning XQuery 1.0.

• XQuery 1.0 and XPath 2.0 Data Model
• XQuery 1.0 and XPath 2.0 Functions and Operators
• XML Path Language (XPath) 2.0
• XQuery 1.0: An XML Query Language
• XQuery 1.0 and XPath 2.0 Formal Semantics
• XQuery Update Facility Requirements - very important
• XML Query Use Cases
• XML Syntax for XQuery 1.0 (XQueryX)
• XSLT 2.0 and XQuery 1.0 Serialization

(via Norman Walsh)

A comment at Cedric Beust's weblog mentions Savant, which is an extension for Ant that enables dependency handling. Combined with Ant's <import> and <macrodef> elements, this can offer much of the functionality Apache Maven offers.

But Maven is more than dependency handling and better re-use and modularization of build scripts. It allows you to bundle your build-scripts as plugins and allows easier distribution, it creates project websites with unified look and feel, provides a consistent project structure, supports nearly every tool you might or might not use to analyze your code, and as it includes ant, can do everything Ant can do. See Rick Hightower's weblog for more Maven-advocacy.

On the downside you have to learn: writing project object models, which is not that hard, and - if you would like to customize the build process - learn to write Jelly scripts, which is not hard either, but scripting in XML scares many people.

Bruce D'Arcus recommends following workflow to writers with a strong need for support for bibliographic data. His solution does not only include only DocBook-XML (he recommends the new RELAX NG based DocBook NG), but also some cutting edge tools like the eXist native XML Database Management System (there are some others available, but eXist is Open Source and works), a tool called citeproc to process the bibliographic data, which is a collection of XSLT 2.0 Stylesheets for a processor like Saxon 8.

I have to try this workflow when I write some papers for my university next time. It sounds like an interesting way to keep track of all your <biblioentry-elements.

Martin Probst complaints about overly complex XML-APIs and recommends the use of XQuery as a language that can be used to work with XML data programatically, that does not suck.

In most cases XQuery is more than people need in their applications. It is very powerful and you can build complex applications with XQuery, but there will be no one to write a complete CRM or ERP using XQuery. Instead they are going to embed XQuery in their existing Java, C++, C#, whatever-code. An XQuery-API that allows you to seamlessly access parts of one or more XML documents might be a great helper.

In fact XPath 2.0 might be sufficient for most applications. If you can do the for-loop in your favorite programming language, why should you bother to learn the syntax of FLOWR-queries. If you need the contents of a special element /foo/bar\[@what='ever'] should be enough. This makes XPath with a good API an ideal replacement of DOM.

/foo/bar[@what='ever'] is just easier to read, write and understand than

Document document = ...
foreach (Element e1 : document.getChildElements()) {
  if (e1.getLocalName().equals("foo")) {
    foreach (Element e2 : e1.getChildElements()) {
      if (e2.getLocalName().equals("foo")) {
        if ("ever".equals(e2.getAttribute("what"))) {
          //do something
        }
      }
    }
  }
}

which is not real DOM, but a much simplified pseudo-code-version.

But I like SAX much more than DOM. It is faster, has reduced memory-consumption and I you have to think some seconds before you start to work, which leads to code that looks as if someone has thought about the problem before starting to write something.

It is obvious that a tree-based approach that is used by XPath cannot be used to wrap a SAX-like API. Perhaps STXPath, which is used for Streaming Transformations for XML (STX) might be a solution. This seems the be exacly the problem David Megginson already thinks of .