Planet KDE

thursday night we went to the premiere screening of a friend's film called "the end". the writer/director jeremy also played a key role in the film due to a dearth of local male talent who come out for auditions for indipendant "zero-budget" films. it was shot on video but the quality was still excellent; amazing how far that technology has come. "the end" is a feature-length psychological thriller and played to a packed house of a few hundred people at a local theatre. hopefully it'll be hitting the upcoming festival circuits and get jeremy the recognition he and his crew deserves for their effort. it may not have been a hollywood blockbuster, but i enjoyed it thoroughly. it was sophisticated, funny, well shot and well acted.

yesterday i spoke at a small invitational conference lexi.net puts on each year for its clientele. i spoke about kde and online identity. a good portion of the presentation was dedicated to kwallet, though we also looked at encryption support in email, instant messaging and the web; web services integrated into desktop applications; and hardware and kernel level identity solutions. the presentation was kept fairly non-technical due to the mix of people attending though we did go into more technical details in a few places. a pdf of the slides i used can be found here.
.

the attendees seemed engaged and impressed, particularly by kwallet. the idea of a fully auditable code base for storing passwords and sensitive data really struck home for a lot of people. one person who deals with securities noted that it would be great for their work since they have a lot of online accounts they need to deal with on a daily basis which contain sensitive information. a privacy professional was nodding along the whole time as well. kwallet could certainly be improved, and i pointed out some of those improvement points such as being extending into a single sign on system, improved identification of applications on the bus, access control on information in the wallet, etc. george staikos has been the sole author of this stuff and it's really compelling. the code base isn't very large either so would make a great entry point for someone interested in these sorts of things to get involved with kde.

this morning an email arrived in my inbox from one of the attendees letting me know they had downloaded kubuntu to give it a try. they had a quick question about qemu as well. always great to see such quick results.

if you have a chance to promote kde and the free software desktop locally i totally recommend it. it's very energizing and rewarding. if you don't have a chance to do so, think about making one. universities usually have interest groups for computing and most cities have various technology and business social groups that are often looking for speakers and interesting topics.

November 18, 2006 07:59 PM

How to design APIs for XML is debated daily, and has been done so for long. For too long. Now ages ago, companies formed at W3C to design the DOM, using language neutrality and document editing with load/save persistence as goals(it seems, and some says). But some needed other things, such as a streamed, less verbose approach and hence SAX was brought to use. Others found SAX cumbersome to use, and StAX was deployed. And so on, and so on.

One urge I have is to cry out: why can we never design a sensible API? But that reaction wouldn’t be justified. Software is the implementation of ideas. When the software has to change, it’s the reaction stemming from that the ideas(the requirements) changed.

Afterall, SAX works splendidly for some scenarios. I don’t expect one tool for all scenarios, because XML is used in too varied ways. But still, even though one can expect tools to become obsolete and that one size doesn’t fit all, the current situation is more worse than what is reasonable.

In Qt, the dilemma the XML community has is present as well, painfully. The QtXml module provides an (in my opinion poor) implementation of DOM, and SAX. Something needs to be added in order to make XML practical to work with using Qt. Some of the ideas I’ve heard are by the book: add StAX as a streamed-but-easy-to-use API, and a XOM-like API for doing in-memory representation. The latter would be an API that doesn’t carry the legacy of XML’s evolution(the addition of namespaces, for instance) and in general do what an XML API is supposed to do: be an interface for the XML and therefore take care of all the pesky spec details, which XOM does in an excellent way.

If Trolltech added StAX and a XOM-like API to Qt no one could blame them. Other do it and it is the politically correct alternative at this point of our civilization(just as DOM once was). But I start suspecting that it’s the wrong direction. That the step of learning a lesson of adding yet another API could be skipped, in favour of jumping directly to what would follow.

Let’s look at what XML is:

It is a medium, a text format for exchanging data, specified in XML 1.0 and XML namespaces. XML is absolutely terrific at this. The IT’s history is tormented with interoperability problems such as encoding issues. XML solves all that in one go. It abstracts away from primitive details, and provides a platform. This is why XML is popular.
A set of concepts to express ideas. This is all that about elements and nodes formed in a hierarchial structure(that from a reader’s standpoint can be difficult to distinguish from the text representation, since we humans instantly see the logical structure when looking at an XML document). Exactly what that is, is not so obvious. The different appproaches are often referred to collectively as data models, and there are plenty of them: the XPath 2.0 Data Model, the XML Information Set, the PSVI infoset extension, the DOM(that it stands for Document Object Model is a hint), and the list goes on. These are all different ideas to what a sequence of characters arranged to be valid XML, actually means.

That one can view XML as consisting of these two parts reveals a bit about how XML has evolved. First XML 1.0 arrived, taking care of syntax details. Later on, this plethora of data models arrived to formally define what XML 1.0 informally specified. Understandably many wants to make the XML specification also specify the data model. The question is of course which one to choose, and what the effects are of that.

But the list of data models doesn’t stop with the above. Those are just examples of standardized models. I believe that one data model exist for each XML scenario.

When a word processor reads in a document with the DOM, the actual data model consists of words, paragaphs, titles, sections and so on. The DOM represents that poorly, but apparently acceptably well. Similarly, when a chemistry program reads in a molecule, its data model consists of atoms.

That XML is used for different things can be seen in the APIs being created. SAX is popular because it easily allows a specialized data model to be created, by that the programmer receive the XML on a high level and from that builds the perfect data structure. DOM allows sub-classing of node classes by using factories and attaching user data to nodes, in order to make the DOM instance closer to the user’s data model.

XML is not wanted. Communication is a necessary evil, and therefore XML is as well. If programs could just mindwarp their ideas, molecules and word processor documents, to another program they would, instead of dwelving into the perils with communicating through XML.

I believe this is a good background when tackling the big topic of providing tools for working with XML. It’s not questions like “How do we design an API that avoid the namespace problems the DOM exposes?” It starts at a higher level:

How do we allow the user to in the easiest and most efficient way go from XML to the data model of choice?

Ideally, the user shouldn’t care about details such as namespaces and parent/child relationships. If the API has to push that onto the user, it’s an necessary evil. It’s again about not getting far away from the ideal data model. The idea is in general already practiced when it comes to the most primitive part: serialization. It’s widely agreed that a specialized mechanism(a class) should take care of the serialization step.

Let’s try to apply this buzzword talk to Patternist and Qt. A QAbstractItemModel is typically used to represent the data, since the data is practically separated from its presentation, with the model/view concept. The user wants to read an XML file, and produce an QAbstractItemModel instance.

Patternist, just as Saxon, is designed to be able to send its output to different destinations. It’s not constrained to produce text(XML) or SAX events or building a DOM tree, it just uses a callback. And that callback could just build an item model. It should be possible to write that glue code such that it works for arbitrary models.[1] With such a mechanism, one would only have to write an XQuery query or XSL-T stylesheet that defines a mapping between the XML and the item model, in order to do up and down conversions.

Using Patternist to directly creating item models might not be the way to go. But I do think one should concentrate on what the user wants to achieve instead of trying to fix the current tools(perhaps it doesn’t matter that the hammer is broken, because in either case a screw driver should be used). And amongst what the user wants to do, I believe converting between XML and the data model of choice is a very common scenario.

In general, it all seems interesting to write “interactive” output receivers and trees with Qt. One would be able to write queries/stylesheets that generate widgets, write queries over the file system or QObject tree, etc. But that’s another topic.

November 18, 2006 06:44 PM

About

Subscriptions

Planetarium

/dev/urandom

November 18, 2006

Aaron Seigo (aseigo)

movie priemiere, lexi.net event

Frans Englich (FransE)

XML APIs

Johan Thelin

Doing hard time

Logitech + Cygwin = frustration

SpeedCrunch for the Mac

Winter View

See the Path

Speedy Crunching on the Mac