XForms Everywhere

Are you a genius? Of course you are! Then the same question written in XPath, you = genius, returns true(). In this case, you != genius must return false(). No rocket science here: if A = B return true() you expect A != B to return false(), and the other way around. Or said otherwise, you expect A != B and not(A = B) to be the same.

In most cases they are, but not always. This is because of the way XPath compares sequences: the result of the comparison is true if and only if you can find one value in the first sequence and one in the second which when compared with the specified operator returns true(). This means that:

• If at least one of the two sequences is empty, the comparison always returns false. So both expressions () = 42 and () != 42 return false().
• For some sequences, you can find pairs of values, one in the first sequence and one in the second sequence, that both match the = and != operators. For instance: (1, 2) = (1) returns true() because 1 is in both sequences. But (1, 2) != (1) also returns true() because 2 from the first sequence is not equal to any value from the second sequence.

Is this all here to confuse you? Certainly not; the way comparison works in XPath has a number of benefits, maybe the most important one in practice being that you can use the = and != operators to check if a value is present in a sequence, like some sort of contains() function. For instance x = (1, 2, 3, 5, 8, 13, 21, 34, 55, 89), where x is of type xs:double return true() if x is Fibonacci number lower than 100.

We are glad to announce that we will talk about XForms and Ajax at Solutions Linux - Solutions Open Source in Paris. This will take place on Thursday, February 1, 2007 afternoon, in the “Web 2.0 - Towards an application-oriented web” (”Web 2.0: vers un web orienté applications”) session. Here is the abstract:

Handling interactive web forms with XForms (Gérer les formulaires web de manière interactive avec XForms)

When talking about Web 2.0 technologies such as Ajax, not many think about XForms. However XForms, a W3C recommendation since 2003, is gathering momentum as the same technology that enables Google Maps also allows deploying complex but user-friendly enterprise forms to the majority of deployed web browsers (including Internet Explorer, Firefox, Safari and Opera) without the need for plugins or other client installation.

In this presentation, we introduce XForms technology, explain the basics of Ajax-based XForms, and show how you can use open-source software to implement end-to-end forms solutions based on standards such as XForms and XML, while using cutting-edge technology like Ajax to make your forms user-friendly and easy to deploy.

The presentation will conclude with a series of demonstrations based on open source software.

The talk will be in English or French depending on the audience.

• REST and Resource Names. A few weeks ago we upgraded our DMV Forms example to access its pure XML (eXist) persistence layer through REST APIs. Creating a new document didn’t work yet, because it was not clear how to easily create new identifiers for new documents. This is now fixed, thanks to the implementation of the XForms 1.1 random() and digest() functions, which allow us to create nice unique (at least within a single application) document names.

• REST and Flickr. On my spare time, I spent some time with the Flickr API. Our Flickr Resize example already illustrates a simple use of the Flickr API from XForms, but this time I wanted to see how to implement Flickr’s authentication, directly from XForms. The new XForms 1.1 digest() function solves this like a charm. In addition, in order to support Flickr, the XForms urlencoded-post submission method is now implemented. Funny that the Flickr doc just tells us to “POST” data, but does not specify what encoding to use (posting XML, as you would expect from a REST API, doesn’t work with Flickr). Feel free to look at flickr-api-model.xml in the latest builds.

• JavaScript Compression. We played with Dojo ShrinkSafe to produce more minimal (compressed) versions of our JavaScript files (all the YUI files were already available in compressed format). This worked great and all files are now compressed, except for xforms.js which is still causing some trouble (but it would benefit the most). Apparently, ShrinkSafe is not quite 100% safe yet. As a reminder, you enable minimal resources by setting this in properties.xml:

  <property as="xs:boolean" name="oxf.xforms.minimal-resources" value="true"/>
  

• Submission Performance. With XForms logging on, we now log the time spent in XForms submissions, which is invaluable for performance tuning.

• XPL Profiling. We added an unofficial, experimental page to view profile data from XML pipelines. Enable tracing into the session with this property:

  <property as="xs:NCName" name="processor.trace" value="org.orbeon.oxf.processor.SessionTrace"/>
  

  Then load an OPS page, and in the same session, open /profiler/xpl/ to see the results.

• XForms Dialogs Coming Soon. We investigated the possibility to use the YUI panel to create dialogs in XForms. This will be implemented soon.

• JBoss Compatibility. JBoss 4.0.4 classloading and log4j don’t play well. We added an option to disable logging initialization which works around this issue.

• Output Formatting. We now format more number data types with xforms:output. This in particular allows you to nicely format decimals.

• Bug-Fixes. This week had a few notable fixes for bugs reported by users, including a focus issue in repeat that could cause the wrong row to be deleted, and an unexpected Java exception occurring after a submission error.

You have read about using IntelliJ as an XML editor on this blog before, and I would like to share a tip with those of you who are now using IntelliJ¹.

Yes, I do like IntelliJ, but I have to admit that it comes with its own set annoyances. In particular, when alt-tabbing from another application to IntelliJ, it used to just freeze on me for a few seconds. And that happens a lot with web development, say, switching back and forth between IntelliJ where you are editing a CSS file and IE which more stubborn than a mule and more dumb than a donkey still doesn’t render that page the way you want².

The solution is pretty simple: give IntelliJ more memory. You can do this by editing the bin/idea.exe.vmoptions (on Windows) file, which you can find in the directory where IntelliJ is installed. It looks like setting the maximum heap size to 256 MB is enough for the projects I am working on, but your mileage may vary. Also, as I do for the VM running Tomcat and Orbeon PresentationServer, I set -Xms and -Xmx to the same value.

While people are busy writing about what Google is doing or what they might do in the future, I would like to stop for a second and look at what they have not done. Google is pretty strong on collaboration tools: they have email (Gmail), chat (Google Talk), forums (Google Groups), and blogs (Blogger), amongst others. But Google doesn’t have any Wiki or Wiki-like tool. Doesn’t that get you thinking?

Two conditions have to be satisfied for a Wiki to be an effective collaboration tool:

1. The community using the Wiki must work towards a common and specific goal.
2. The community using the Wiki must be large enough relative to the number of pages in the Wiki. In other terms, we get into troubles when the page per person ratio gets too high.

If the two conditions are not met, the Wiki quickly become disorganized. Information becomes hard to find. And even worse, it gets harder to know where new information should be posted, which discourages people from posting new things on the Wiki.

So what happens in those cases? Does it mean that collaboration is not possible? No, it just means that a Wiki is not the best tool. The solution is instead to have a document-based approach. Imagine Word and Excel, but with documents entirely created, edited, and shared online. And in fact, you don’t need to imagine: Google just did that with Google Spreadsheets and Writely they acquired earlier this year, which they put together under the just released Google Docs and Spreadsheets.

Google Docs and Spreadsheets is a collaboration tool. Some will go as far as saying that it competes head-on with Wikis. I think that instead it complements Wikis, allowing more efficient collaboration in those cases where there is not a strong enough overarching goal or a large enough community to make a Wiki effective (which, in my experience is the case more often than not). Google Docs and Spreadsheets, and more generally the document-based approach, provides a good collaboration solution because:

• Each document might be larger than a Wiki page, but it is much smaller than a whole Wiki. So it is easier to find a common goal amongst people working on the document, and keep the document organized.
• While Wiki pages need to be constantly kept organized, documents are more like emails: you focus on your current emails, those are in your inbox or at the top of the list. Older emails are still there, you can still find them, but they don’t get in your way. You don’t need to keep them organized. The same is true with documents: older documents and spreadsheets that you haven’t even looked at recently will just fall to the bottom of the list.
• Everyone is very familiar with the concept of document: We know we can send them around. We can have each document shared with a different set of people. We can archive them. We can save them in a format that allows us to work on them while we are on a plane…
• And finally, while this might be a implementation deficiency on the part of Wikis, it is an important one: documents are WYSIWYG, Wikis are not. Documents don’t have a “view” and an “edit” mode, with the “edit” mode sometimes even using a cryptic syntax. With documents, and in particular Google Docs & Spreadsheets, when you have a document in front of you, you can always modify it right there. It is even more than WYSIWYG: in the case of Google Spreadsheets if you and another person have opened the same spreadsheet on two different computers, as soon as modify the content of a cell and press enter, your modification will show up right away on the other person’s computer. The same is true with Google Docs: two or more people can edit the same document at the same time and see with a small delay modifications done by other parties. This is collaboration.

Wikis are used for many different purposes. They are different things to different people, and my comments here are based on my experience. I don’t pretend to be in a position to have an overarching conclusion regarding Wikis. Instead, I would be interested to read what you think. Is your experience different? Just leave your comments here :).

We have been shipping the eXist XML database with PresentationServer for quite some time now, but have only started using eXist on some of the “real-life” projects we are doing for our clients about 6 months ago. eXist is open source (under the LGPL license, the same license we use for PresentationServer), lightweight, supports XQuery, has been selected as one of the technology of the year 2006 by InfoWorld, and is a very popular XML database amongst people doing form applications with PresentationServer.

With all this, eXist stands as a solid XML database. Until recently, the PresentationServer processors you use to connect to eXist were not documented and figuring out how they worked was entirely left as an exercise to developer. Our documentation about eXist now lists the 4 processors you can use to query, update, delete, and insert data in eXist. Also, the new how-to section gives a few “tips and tricks” that you might find useful, as for instance how to run queries in eXist from the command line. What are your favorite “tips & tricks” for eXist? Share it with the community by posting comment here, or on the ops-users list!

We now have the latest cover of the book, scheduled to come out some time in November. From left to right: Eric, Danny, Erik, Joe, and Alex. You can already pre-order it at Amazon.com.

The XML Processing Model Working Group at W3C, of which Orbeon is a member, has just released the first public working draft of the standard XML pipeline language tentatively named “XProc”. Such a language was the missing link between many XML technologies, which makes this is an important milestone.

At Orbeon we designed and implemented our own XML pipeline language, XPL, back in 2002 because there was no standard for XML pipelines, and the existing proposals or implementations back then were not satisfying. Ever since, we have been hoping for a standard, and in fact we did more than hoping for it since we talked to interested parties about the best course of action and wrote a formal specification for XPL and submitted it to W3C. The XPL Submission was published by W3C in April 2005.

While several factors have contributed to the creation of the working group, including Norm and Henri’s dedication to the cause, we like to think that the XPL Submission was one of the triggers involved, and that at the very least it made clear that there was serious interest in the XML community for an XML pipeline standard.

So what’s in this first public working draft? First, it is just that, a draft, but it represents almost a year of efforts by the working group. While the current syntax is not identical to that of XPL, XPL users will recognize similar constructs, like p:choose and p:for-each. Conceptually, the processing model is also similar, with “steps” consuming and producing XML documents. XProc adds to XPL the ability to handle sequences of documents on inputs and outputs, parameters, as well as exception handling. If you are familiar with XPL, there are good chances that you won’t have difficulties switching to XProc.

In light of this, how do we see the future of XPL? The answer is that we plan to implement XProc once it is closer to being a recommendation, and that this will lead to progressively phasing out good old XPL. We hope to be able to adapt our current execution engine to XProc, so that it can support both XPL and standard XProc.