QIODevice and QXmlQuery

I have not yet seen an API for XQuery in which integrating the data model, atomic values, nodes and all, into the interfacing language has been a walk in the park.

At the top of the list of things people tend to ask on the forums around is “How do I get XML represented as a sequence of bytes in Java/C++ into my query?”, whose result is clear — a tree fragment for the query to operate on — but whose method for reaching is not that given if you ask me.

There is no “bytestream” type in XQuery. Should the user build the tree herself and then pass the tree to the query? Should the implementation in some voodoish way be instructed how to treat a string or custom type? Shouldn’t the query engine do it such that its scope of analysis is increased and its done the way it prefers it?

What I sense have been the problem with some solutions is that they mix the data, the bytestream, with interpretation.

In Qt this manifestate itself with that the content of a QIODevice should appear in a QXmlQuery. The way it’s now provided, is that when a QIODevice is bound to a variable using QXmlQuery::bindVariable(), the query sees a URI(an instance of xs:anyURI) which behind the scenes maps to the QIODevice the user bound. Hence, if the purpose is to build an XML document, one passes the URI to the builtin fn:doc() function.

I hope this is clean. Since it’s handled like any other URI, custom extensions stays at a minimum, error reporting is consistent, and the interpretation hasn’t been coupled with the data. For instance, later on I hope to merge in support for XInclude and XQuery Update, and in those cases the URI is again simply passed to for instance fn:put().

One can weight quite well on URIs and the abstraction the XPath Data Model provides, it seems.

Blue Room

You are in an empty squared room painted blue. You perceive it as sitting on a meadow where a girl in front say to you: “Dear, you’re not not sitting in a meadow here with me, you’re in a blue room.”

KDE’s URIs

Significant for KDE’s IO-handling is its use of proprietary URI schemes. As recently mentioned on the kde-usability list, there’s for example the home:/ scheme that when entered into Konqueror displays the content of the /home folder, more or less.

If “proprietary URI schemes” sounds all evil and wrong, it does so because it is. Registered schemes have an agreed meaning in a wide community. Proprietary URI schemes is like any other kind of interoperability breaking — like when Microsoft decides to add its own modifications and extensions to Javascript and CSS. Any piece of software understands file:///home while its only KDE applications using KIO that capiche home:/. That’s the best case scenario. Perhaps someone decides to behave and standardize a scheme by name home:/, which happens to have different semantics to KDE’s.

This is not a theoretical problem, see report #126847 for an example of where these homemade schemes cause trouble.

While I think I am correct in my bashing so far, one surely can add nuance to it. Many would probably say that KDE’s proprietary schemes is a necessary evil for making the usability of URIs reasonable. For example, they would claim that man:/cmake is better than tag:kde.org,2006:man:cmake(a use of the tag scheme to produce an interoperable URI).

I think arguing about URIs’ usability is in the wrong ball court, because URIs have bad usability no matter what. As soon URIs are advertised in commerials on TV, it’s never http://www.tv2.dk, they elegantly let it read tv2 dk.

KDE’s widespread belief in URIs perhaps stems from that developers fail to abstract from themselves and see it from the user’s perspective. That one can enter “gg: wikipedia” in Konqueror to automatically google for the term “wikipedia” is touted like the invention next to sliced bread. But how should users — except for the geeks — know how to use gg:, let alone know it exists?

The same could be seen in discussion on the kde-usability list: some didn’t know the home:/ scheme exists, which to me is fully understandable. I don’t see how users should be able to learn the pesky syntax details of using home:/, let alone a reason why.

Therefore, I don’t believe the right way to solve URIs’ poor usability is to use proprietary schemes. For example, googling quickly should be done with one of the well known approaches browsers take, and navigating man pages should not be enabled by having memorized the man:/ scheme, anyone should be enabled to it via a friendly interface.

Dropping down to the command line for interfacing the user is about a two-decades step backwards in usability.

PS. If you don’t want to use a proprietary URI scheme for your app, check out the KDE URI Guidelines.

Information Overload

As for others my days consists of an astonishing amount of information: ideas, ideas and ideas on mailinglists and blog feeds. For some reason it is first now I’ve realized I must prioritize. Perhaps I’m getting old.

Not so Old Fashioned Anymore

I’m usually quite an old fashioned guy. Do I use one of those fancy new media players for my music? Nooo, I use the mplayer command line utility, and shell’s auto-completion for searching(so I call it). Do I use Kontact’s fancy todo-plugin? Nah, I have literally a stack of papers for “organizing” my daily work.

However, some days ago, don’t ask me why, I thought “let’s try out all those modern thingies”. And so I did.