latest entries from

Piotr's R&D blog

This is the most influential paper award presentation. Michael Jackson (from the panel) is rehashing some of the same points re: normal vs. radical design. From what I understood, normal design is based on experience and doesn't deviate too far from things that have been tried and are known to work. Radical design tries to build something new, based on theory or formal models. The best that should be expected of a radical design is that it not be completely broken, and provide the motivation for further design work. I guess that software engineering is doing mostly radical design so far, and Michael would like to see it move towards normal design. But is it possible that the nature of software precludes normal design a priori?

Pamela Zave is now talking about applying some of these principles to telecommunications. I didn't see the relationship to Michael's talk, it seemed to be about an architecture for composable telecom system features. I'm afraid I didn't quite follow, though.

Reef's CVS adapter is (provisionally) done. Reef will now connect to a CVS repository, seek out any changes, update a local working copy and analyze the log data to present a unified modifications report. This report is used by following phases to enable only incremental processing to be done, hopefully greatly enhancing the performance of the application on huge code bases.

The modification extraction is particularly interesting. I found out that CVSNT, an alternative but generally compatible implementation of the CVS system, tags log entries with automatically generated commit IDs. This allows for easy reconstruction of the atomic commits actually performed by the user, and was not mentioned in the papers I read about the topic. Of course, if the commit IDs are not present for any reason, Reef will use a standard sliding-window algorithm to synthesize best-guess multi-file commits. The papers made this out to be a big deal, but I found that (with the backing of an XML database that supports XQuery) the algorithm comes down to less than a screenful of code. Once you've fixed the bugs in the database, of course... ah, the wonder of open source projects!

Some things that the adapter won't do yet is deal with module aliases or branching. To deal with branching, I'd have to figure out a merging mechanism for diagram edits, which I frankly don't feel like doing yet. Hopefully there's enough projects out there without branches that will still find Reef useful. As for module aliases (and other CVSROOT/modules tricks), does anyone know how prevalent they are in practice? I suspect it should be possible to work around at least a few of the problems, but I'd rather not unless it blocks a significant quantity of possible deployments.

If one does not buy into the Semantic Web premise of "one metamodel to rule them all" (aka RDF(S)/OWL) -- and this approach does seem unable to generate much traction on the web -- then one needs to worry about transforming model instances between different schema. Faced with the task many programmers will resort to an ad-hoc imperative solution in their general-purpose programming language of choice. This has disadvantages in the areas of transformation maintenance and engine features such as incremental transforms, transform traceability, bi-directional transforms, etc.

I've been thinking about the problem recently, and serendipitously found two related postings in my growing list of RSS feeds. The first was an annoucement from alphaWorks of the Model Transformation Framework (MFT). This framework defines a declarative mapping language (yay DSLs!) and an engine for transforming Eclipse Modeling Framework (EMF) models according to the mappings. The engine has some nice features like allowing incremental reconciliation of models, supporting nested (and, presumably, recursive) mappings, and allowing your own Java-coded constraints to be plugged in. The development environment (supplied as an Eclipse plugin, naturally) sports a syntax-aware mapping editor and a source-level mapping debugger.

The MTF appears to be a very nice solution if you're willing to buy into the EMF. On the other side of the fence, though, we have good ol' plain and universally-adopted XML. The canonical way to transform XML is XSLT (the XML Styling Language: Transformations; bonus points if you can name other XSL languages without resorting to Google), but since its inception the language has gained a reputation as ungainly, underpowered and unmaintainable. This is all about to change, if you believe Kurt Cagle, with the advent of XSLT 2.0. While in general I'm a fan of the loosely coupled, "scruffy" approach (as opposed to the formality of MOF and EMF), I'll have to read through the (all too long) spec to see if the details are up to scratch.

Where does that leave model transformation in Reef? I'm not sure yet. The first layer of transformations, from external artifacts to a matching low-level model (e.g. Java source code to a simplified XML model thereof), is implemented as a bit of unidirectional Java glue between parser libraries and the XML database. This works well for this relatively simple task and is unlikely to change. The next layer of transformations, from low-level model to visual UML model, is a bit of a challenge, though. These transformations need to be incremental (in more than one sense) and allow for a degree of user control. Furthermore, some of the transformations need to be able to run client-side, in an SVG browser. For the sake of sanity, I'd rather use the same code for server-side and client-side transforms, which probably leaves me with a custom JavaScript engine based on XPath 2.0, whose support is mandated for SVG 1.2. On the server-side, I'll need to cook up some way to link the engine to the XML database, probably through Rhino. Looks like some fun times ahead...

An interview with Sir Arthur C. Clarke about how information and communication technology will reshape humanity. Clarke gives answers that are sometimes well-thought-out, sometimes whimsical, but always a good read. I especially like his comment on censorship: we don't need censorship, we need information maturity, the ability to discern what information is good for us to look at.

As a follow-up to my JavaScript Revelations mini-talk, here's a list of some resources to dig deeper into the subject:

• A good, coherent set of short articles on Douglas Crockford's site.
• Doc JavaScript has lots of fairly in-depth articles about advanced JavaScript stuff, including a series about JScript .NET.
• jsIndex is a good gateway to more resources on O-O JavaScript.
• In the talk, I also referred to the future: JavaScript 2.0, Spice (combining JavaScript and CSS?) and JScript .NET (lots more info out there).

I'm still looking for more (coherent) information about Microsoft's HTML components (previously known as Behaviors).