XForms Everywhere

John Boyer (of IBM and co-chair of the W3C XForms Working Group, of which Orbeon is an active member) mentions on his blog two new publications from the XForms Working Group:

• A new collection of errata for XForms 1.0 Second Edition was published on July 12, with welcome precisions on:

  1. The type model item property (MIP), used to validate instance data based on XML Schema datatypes.

  2. The description of the new deferred update behavior of actions. There already was a defined behavior for deferred updates, but it did not take into account that actions could trigger further events, handled in turn by new actions. The updated mechanism ensures that a smaller number of recalculations, revalidations and controls refreshes are performed even in the case of such sequences of events and actions. It also makes it easier for form developers to understand when automatic recalculations, revalidations and refreshes occur. Orbeon PresentationServer (OPS) already implements this updated mechanism.

• A new working draft of XForms 1.1. The Working Group is working hard on XForms 1.1, the next version of XForms, with further updates to the draft planned for August and a three-day face to face meeting in September.

Stay tuned for more XForms updates over the next couple of months!

As a web application developer (or just as a regular human being), you have probably wondered at some point: why do online PDF documents open in my HTML browser window?

This situation goes back many years, probably since the first browser plugin APIs were devised. It probably just sounded like a good idea to browser developers to integrate different types of documents in the browser window. With PDF though, this has many drawbacks:

• The Adobe Acrobat Reader plugin, like any Adobe application, takes ages to start. While it is starting, your browser is frozen and you can’t do anything else.

• When it doesn’t work, it crashes your entire browser, or just freezes it (the case with Adobe Acrobat 6.0 and Firefox).

• When it works, usual browser shortcuts don’t work, including those to close your window or tab, navigate between tabs, go back and forward, etc.

• To make things worse, there is really no reliable warning when you follow a hyperlink that you are going to open a PDF file. So you hang, crash or freeze without any courtesy notice.

When you combine the above with the fact that there is really no useful purpose in opening PDF documents in your web browser, you understand why yesterday I figured that enough was enough and that I would not suffer this anymore.

The good news is that there is a “very easy way” (it’s just four levels of dialogs down, come on!) to change this behavior with Firefox on Windows:

1. Go to the “Tools -> Options” menu

2. Select the “Downloads” tab

3. Open “View and Edit Actions…”

4. Enter “pdf” in the “Search” box

5. Select “Change Action…”

6. Change the selection from “Use this Plugin” to “Open them with the default application”, which should point to Adobe Acrobat, Adobe Acrobat Reader, or your favorite PDF viewer

Phew, that was it. While you are at it, you can change all the other entries that use the Adobe plugin to use an external application, make sure mp3 files don’t open with Apple QuickTime, etc.

The official blog for the Google Maps API announced yesterday the addition of a new feature to their Map badge: continuous zoom. You can test this out on maps.google.com.

At this point, I think choppy zoom would be better name than continuous zoom, as effect as I experience it is far from smooth.

Still, adding zoom is a laudable improvement. But here is something else I would like to see in Google Maps: good maps. Look at the two maps below: the one on the left is from MapQuest, while the one on the right is from Google Maps. Those of you who are familiar with the area know that the two main cities in the Monterey Bay are Santa Cruz and Monterey. Did you notice that they are both missing on the map from Google? I think everyone will agree that a map of the Monterey Bay that fails to show where Santa Cruz and Monterey are is quite a bad map.

If you look carefully a those two maps, you will find other ways in which the map from MapQuest is superior. For instance, the 17 mile drive along the coast going to Carmel, a major attraction in the area, is shown by MapQuest, but there is no even a sign that is a road there on the map from Google. Let’s call this room for improvement.

First a disclaimer: no I am not switching to Rails as a web platform any time soon (XForms is way too cool to build Ajax-based user interfaces), but I happen to be writing a bit about Ruby, Rails and XML in our upcoming Web 2.0 book.

This post is a reaction in shock to the fact that Ruby doesn’t support Unicode. Yes, that’s right! I did quite a bit of research online on this, and it is just a fact: as of Ruby 1.8.4, there is no serious support in the language for internationalization as we understand it in Java or .NET. As per the documentation, a Ruby string is just a series of bytes.

To be fair, some classes like Regexp have built-in support for UTF-8, but this is by no means a universal thing in the Ruby Core API. The good news for Ruby users is that the issue seems to have been recognized (although I have read a fair amount of denial online by people who do not quite grasp what Unicode is for), and support for so-called multilingualization is meant to arrive with Ruby 1.9 or 2.0. But this has been in the making for a very long time.

I read people arguing something along the lines of “Ruby supports Unicode since you can put anything in a string” or “there is no particular reason to support Unicode rather than other encodings”. Now this is just plain wrong, and here is why:

• Unicode is not technically a character encoding. It is true that Unicode assigns so-called code points assigned to characters, and encodings typically do that as well. But Unicode attributes different code points to all the differrent characters of all the languages of the world (at least, that is the goal). With Unicode, you can encode those code points using different character encodings, such as UTF-8 and UTF-16. The real character encodings here are UTF-8 and UTF-16, not Unicode.

• I already talked about how Java was broken with respect to Unicode because of its 16-bit characters and lack of even minimal support, until Java 1.5, for surrogate pairs in UTF-16. But by looking at strings as sequences of bytes, Ruby is not even at that level of brokenness. At least Java and C# are correct in 99.99 percents of the times (making up this statistic, of course, based on the fact that Unicode supplementary planes are very rarely used today). Not using Unicode means that methods and classes must special-handle encodings such as UTF-8, like Regexp does. Not having at least UTF-8 or UTF-16 support in strings and having other “encodings” as alternatives means that it is difficult to know what to expect when you look at a byte in a string.

• It is widely recognized that using Unicode is the best available solution to provide internationalization. Witness the fact that Java (since 1995), .NET, Windows, MacOs X, and many Unices, as well of course as XML, have made Unicode central to their text handling. There is a reason for this, which is that so far only Unicode allows you to represent all the characters of all the modern languages (and many dead languages as well). It is probably not perfect, but take your issues and problems to the Unicode Consortium.

But this is fairly well-known, and I have come to the conclusion that the whole issue is the good old one of Han unification. According to Wikipedia, “most of the opposition to Han unification appears to be Japanese”. And guess what: the original author of Ruby Yukihiro “Matz” Matsumoto, is Japanese, and Ruby has lots of Japanese users. This is no way a criticism of Japan (I love Japan), but a historical explanation of the fact that back in 1993-1995, when Ruby was developed, while chosing Unicode was a no-brainer for Java, it was not the case for Japanese developers.

My current understanding (and I may be wrong) is that with the latest versions of Unicode and the clarification of the relationship between characters and fonts should make the point quite moot, and there is really no reason not to standardize on Unicode as the internal representation of characters. So go Ruby, be bold and integrate Unicode already!

NOTE: I found this interesting and recent Unicode Technical Note on the subject of the encoding of the Han Script (scroll to the second subtitle). It is written by the Ideographic Rapporteur Group which advises Unicode and ISO on those matters, with members from China, Korea, Japan, Taiwan, and Vietnam. This comforts me in the idea that Han unification in Unicode is a good idea.

XQuery has been designed and is used today as a language to query XML data sources, including XML databases. So you would expect that XQuery offers the same level of expressiveness for XML data that SQL offers for relational data.

A quick glace at the language would make one think that this the case. But as I was writing some XQuery for a client last week, I stumbled upon a problem: where is group by in XQuery?

When looking at different types of queries sent to a database, you can make a distinction between queries that retrieve some piece of information and queries that aggregate and analyze the data stored in the database. This is the distinction between getting the detailed information about a specific invoice, or the list of clients located in California, and getting the average raise employees in the company got last year per department, or top 5 selling products by product family. You can easily write those two last queries in SQL with a group by. It is possible but harder and more verbose to write the equivalent in XQuery.

In fact, the problem has been recognized by Vinayak Borkar from BEA, and he suggested an extension to the XQuery syntax to solve this issue in his paper Extending XQuery for Grouping, Duplicate Elimination, and Outer Joins. Hopefully Vinayak’s suggestion or a similar extension will be added to the next version of XQuery. In the meantime database vendors will maybe choose to implement extensions to XQuery for that purpose.