One of the hard things I think about at work is the implications of Data Modelling practices vs XML schema development practices. As an example, there are a lot of folks in the DoD who are enthusiastic about the Command-and-Control Information Exchange Data Model (C2IEDM), a data model developed by the Multilateral Interoperability Programme (MIP).

I have concern that Data Modelling, as a practice, results in good ways to represent information at rest, but that it does not do a good job of developing mechanisms to exchange information. I.e. data modellers define database structures, but do not define languages.

There is a tendency to create good data models, and then run a script to generate the associated XML schema. I worry that this is not sufficient – the resulting XML schema will be good for database replication, but not be useful for anything else.

As an aside, the documentation of the 2002 version of C2IEDM (known as the LC2IEDM) is 315 pages long. The US Air Force, (and others) use a XML schema known as Cursor-on-Target for exchange of C2 data that has 13 elements and can be reasonably documented in about 11 pages. (more here)

C2IEDM and CoT are not pure-competitors; any comparison is not apples-to-apples. In fact, they may be complementary… C2IEDM is a data model, CoT is an XML schema. In other words, CoT can be used to communicate the data that C2IEDM models.

Anyway – most of my concerns are unproven, and understanding the problem will require more thought. I was inspired to blog about this today largely because I stumbled across an article on XML schema: Best Practices called “Global vs Local” that I wanted to link to for future reference that I think has some nuggets that apply to these problems.

I was thinking a lot Friday about the Model-View-Contoller paradigm (aka Model 2) and how it applies to web application design. I was having conceptual issues which I suspected were largely a result of not really understanding the MVC pattern. So I’m trying to sort this stuff out.

In writing this, I ran across Andy Wardley’s article, “MVC: No Silver Bullet“, which shaped my thinking a bit.

The main heartburn that I have with MVC for web applications is the thought that actions are always directed by the Controller, when in fact, often it’s the View that’s getting the clicks. As I was building an MVC framework for my web apps, the Controller was mainly just dispatches to the Views – which doesn’t seem to fit the available documentation on how MVC is supposed to work. If the View prepares the forms, isn’t it the View that should know how to process the form submission?

The answer, according to what I think is the seminal paper on MVC, is this: “Each view is associated with a unique controller and vice versa.” This leads me to wonder: if there is a one-to-one mapping between Views and Controllers, why are they distinct at all? In a rich-GUI environment, I suppose separating out the View and the Controller might make some sense; the View knows how to display the Model, and the Controller processes the mouse-clicks and keystrokes. Since these are very conceptually different, they deserve different classes. That said, in a web environment, the only events are HTTP requests – either page-GETs or form-POSTs – and are more intimately related to the underlying pages. For a pure GET, the Controller only has to dispatch to the right View. For a POST, the Controller should theoretically update the Model, and then refresh the View. That said, to me it makes more sense to keep the form generation code and the form processing code in the same module, which means the View. So the Controller, in a web framework, ends up being just a dispatcher.

I think that the Sun definition of “Model 2” is pretty close to this model, and is somewhat divergent from the Smalltalk MVC pattern. (But that’s okay.) Likewise, the flow picture associate with Catalyst, seen below, seems divergent because it puts the controller completely in charge, rather than having that close one-to-one relationship with the views.

Note that I’m not trying to suggest that the View does the real work. Rather, I suggest that the Model does the work, but that the View marshalls the inputs.

Bought Megan a Mac Mini for her second birthday. She loves it and it's convenient to have a computer up-and-running on the main floor all the time. (Zette and I each have laptops, but they float around and the batteries run out.)

We're using the Microsoft Wireless Optical Desktop for Bluetooth with the Mini, which works pretty okay. I had some issues at first getting them to talk reliably, but setting the Microsoft Keyboard and Mouse as 'favorite' bluetooth devices seems to have solved the problem. We'll see how useful it is to have keyboard and mouse that are battery-powered.

I also upgraded my laptop to the latest stable release of Ubuntu, codenamed "Breezy Badger". I did it mainly because I read a favorable review of Network Manager, (which aparently was not available for the "Hoary Hedgehog" release of Ubuntu), but when I installed NM, it doesn't seem to come up. Have to troubleshoot that later.

I had some issues with Apache2::Reload and Class::DBI not playing nice together. The problem s something about CDBI not wanting to over-write existing symbols when it reloads classes. I found a hack on some japanese Perl forum for Apache::Reload, and I ported it to Apache2. Hopefully this helps somebody.

This is the modified section of /usr/lib/perl5/Apache2/Reload.pm, version 0.09:

if ($mtime > $Stat{$file}) {
my $package = module_to_package($key);
if ( UNIVERSAL::isa($package, 'Class::DBI') ){
no strict 'refs';
warn "Apache2::Reload: clear the symbol table of $package\n" if $DEBUG;
%{"$package\::"} = ();
}
ModPerl::Util::unload_package($package);
require $key;
warn("Apache2::Reload: process $$ reloading $package from $key\n")
if $DEBUG;
}