Back to the Drawing Board for OOXML?

Even some pretty shady manipulation of the various national committees doesn't appear to have helped Microsoft much in their bid to get OOXML, the proprietary format describing Office documents, declared an international standard. The ISO/EIC Ballot Resolution Meeting in Geneva has ended with what can at best be considered an inconclusive result, with only eight of the 'P' countries and ten countries altogether registering any kind of vote on the main matter put to them.

The real problem here is Microsoft's attempt, with the assistance of ECMA, to put the standard through the fast track process; that was clearly not appropriate for a standard of such complexity and political significance. There were over 1,100 dispositions to be decided at the meeting, and only 20 substantive dispositions received any measure of individual attention.

The meeting's convenor attempted to reach a conclusion by bundling together 900 dispositions that had not been discussed and asking the delegations to vote on each without discussion. Unfortunately this led to over 80% of the delegations either refusing to register a vote or abstaining on all dispositions.

The real problem is that rather than being a standard driven by the requirement to describe structured documents of all types, OOXML is simply an XML-based description of an existing proprietary format.If Microsoft truly want to embrace standardization they should now get behind the Open Office ODF format and support it with all the weight they can. This seems unlikely given their prior position on ODF support, which can at best be described as half-hearted. They apparently have a lot of work to do to make OOXML acceptable.

Technically there is now a 30-day period in which the ISO/IEC members can vote to approve the adoption of OOXML. I doubt even Microsoft has sufficient clout to persuade them that this travesty or a process represents a satisfactory basis on which to build an international standard.

Don't Compete and Microsoft Won't Sue

It's obvious that not everyone is happy about Microsoft's most recent attempt to woo the open source community by releasing API details and offering them for use with a covenant "not to sue open source developers for development or non-commercial distribution of implementations of these protocols".

It isn't yet clear exactly what qualifies as "non-commercial distribution", but it's an interesting approach: Microsoft has always complained (sometimes unjustifiably) about the GPL. Now authors of open source products can use the newly-released information as long as they don't gain commercial benefit by doing so. This could be seen as opening up, or simply as a nice piece of spite. It will definitely result in the development of interoperable projects that will take market share away from Microsoft, leaving software dollars looking for other places to be spent.

I suspect that a lot of people will say that this doesn't go far enough, but it's a sea change in Microsoft's approach and has doubtless taken lots of internal discussion. If you develop a commercial product based on Microsoft's patented technologies then you will still need a license from them before you go to market. As long as you believe software patents are reasonable this is nothing to complain about.

Personally I have never thought software patents reasonable, but Microsoft are to be congratulated for trying to promote their technologies in a more open way. Let's hope this is just the first step to fully open standards, only twenty years too late.

Live on Django

After some weeks of planning (our own site always takes second place to clients) I am happy to say that the holdenweb.com site is up and running on a new host as a Django site. Thanks to all those in the Django community who have provided help and advice over the past few weeks.

During the reorganization we also took the opportunity to polish up our standards compliance, and so as far as I know the whole site is now valid XHTML 1.0 Transitional. The server also now has a permanent redirect for requests for the www subdomain to the main domain, which will shorten most URLs by four characters and makes us no-www.org compliant at class B.



Not much else has changed yet, though you will notice that reloading a page now typically displays a different book. The next job is to reorganize the URLs, adding redirects for the existing ".html" locations and cleaning them up to be dotless (since there is no longer any static HTML in the site). We are excited by the possibilities.

Before undertaking this modest project I looked quite hard at both TurboGears and Django, and I have to say that both projects are so good the decision was quite difficult. In the end the thing that swung it for me was the ease of migration of the existing templates and database content. Had I been starting from scratch, however, I might have been tempted by TurboGears. I think that Django just fit my brain better on this one.

And, In Related News ... ?

So I read the output from my daily agent and it includes this gem:

PyWPS releases version 2.0.0

Turns out that even while I was blundering along completely unaware of version 1.something, the PyWPS Development Team have been slaving away to produce version 2.0! Now there's dedication.

Sorry to seem cynical. It is in fact an entirely worthy site, as a look at pywps.wald.intevation.org should convince anybody. As usual my ignorance's limits continue to widen. This strikes me as an amazing opportunity for a bright Python programmer or two to succeed. Geospatial data processing is hot right now.

I am extremely glad to hear that there is an open standard for this stuff. I don't suppose (hope springing, as it does, eternal in the human breast) that Microsoft are on board with the standard. Perhaps they already decided to just buy the committee when the votes come around.

Obscurantism

I may have mentioned before that I have started to use the C# language. Overall it isn't bad - it uses static typing, which I have always found irksome, but the language is reasinably expressive and compact compared with something like Java or C++. Because it is heavily promoted by Microsoft there are any number of tutorial and example web sites, not all of them by programming experts.

Somehow the Java message that it's bad to allow direct access to instance and class attributes appears to have permeated the C# world, I have no idea why. I have just been reading one of the better-written tutorials, which offers the following code as an example if instance creation and manipulation.

static void Main(string[] args)
{
Person Michael = new Person();
Person Mary = new Person();
// Specify some values for the instance variables
Michael.Age = 20;
Michael.HairColor = "Brown";
Mary.Age = 25;
Mary.HairColor = "Black";
// print the console's screen some of the variable's values
Console.WriteLine("Michael's age = {0}, and Mary's age = {1}",
                 Michael.Age, Mary.Age);
Console.ReadLine();
}

As code goes that isn't bad, and apart from the different comment styles and the declarations it could almost be Python. Unfortnately the author has tasted the Java Kool-Aid, and shortly after this example writes

So each object now contains different data. Note that we directly accessed the variables and we put any values we wanted, right? But wait there is a solution to this problem. We will use properties.

There is no attempt to explain what the "problem" is, and you will probably not be surprised to learn that the "solution" involves making the attributes private to the class and then providing public getter and setter methods for instance users. This turns a five-line class declaration into a 32-line one (though to be fair to the author, he does at least include checking code that demonstrates the value of properties in applying class-based logic during assignment).

I have now read any number of texts where instead of something like

class Person
{
public int Age;
public string HairColor;
}

that allows direct access to the instance variables by client code, readers are encouraged to write horrendous code like

class Person
{
private int age;
private string hairColor;
public int Age
{
  get
  {
      return age;
  }
  set
  {
      age = value;
  }
}
public string HairColor
{
  get
  {
      return hairColor;
  }
  set
  {
      hairColor = value;
  }
}
}

which actually offers no benefit over the short version at all. Python users are used to accessing attributes directly in their code, which clearly has performance benefits, and then implementing properties if and when they are required to add logic to the setting or retrieval of attribute values. I just wish that C# users could see that empty getters and setters offer no measurable benefit over direct access to attributes.

Help Wanted!

Another post from Doug Napoleone says (among many other things) "I need to take the very clean and and elegant code of Steve Holden and stuff in into the somewhat organic and undocumented PyCon-Tech code."

It's strange how other people's perceptions of our code can be so different from our own. I am conscious of several areas where that code (published, by the way, as a part of my PyCon 2007 tutorial) really needs revision. But anyway, thanks for the tip of the hat, Doug.

Anyone wanting to help to improve the software support for PyCon should sign up for the PyCon Tech project. It would be a great way to get started in Django in a supportive environment.