You may read my posts on XML.Com and believed that because I blog here I may know a thing or two about XML. Or you may think I am just a lucky idiot. The truth is a little of both!

One of the really convenient features introduced in XSLT 2.0 is Grouping. It is a typical second-generation change in a programming language: Not essential for the language itself (grouping can be done by hand using techniques such as the Muenchian Method), but required by many users and thus a useful addition to the language.

XQuery so far lacked support for grouping, with the same results as in XSLT 1.0: Grouping is cumbersome to implement and potentially slow when not implemented right. The recently published first XQuery 1.1 draft makes only few changes to XQuery 1.0, among them a Group By clause for FLWOR expressions. This should make the language quite a bit more useful, because grouping is such a frequently needed feature.

The other notable addition to XQuery 1.1 is the Window clause for FLWOR expressions. Windows come in two flavors, either tumbling or sliding windows. Windows clauses are somewhat similar to grouping, because they allow specific iterations over the binding sequence (not by grouping the items into new items, though, but by grouping them into windows, which always contain consecutive items). Windows are not that hard to understand when you look at the tumbling window examples and sliding window examples provided in the draft.

So far, XQuery 1.1 looks like a really small and useful set of changes to XQuery 1.0, which is good. Let’s just hope it does not share the fate of XSLT 1.1, which was abandoned and never really made it into implementations. Are there any other changes which should be part of XQuery 1.1? The XQuery 1.1 Requirements list quite a few, including functions for date formatting, numeric formatting, and error processing and recovery. It will be interesting to see how these requirements will be addressed in future versions of the XQuery 1.1 draft.

I wrote a recent article the other day on how Google has decided NOT to use XML for a recent project they open sourced. I received a LOT of very opinionated responses to that post. Unfortunately every one was from a complete MORON.

I just came across an article that announced Google open sourced their ‘Protocol buffers’ but decided NOT to use XML.

It is great that Google is contributing to the community and is showing the world how their system works, but I wonder if the inmates have taken over the asylum. I am a software engineer, so I enjoy the technical information, but I also ran my own company, and evolved to view problems from the business end. If you let the ‘engineers run the show’, then you get a very narrow viewpoint.

I think we have a severe ‘Not invented here’ syndrome inside Google.

My fellow blogger, M. David Peterson posted a very informative blog in relation to Jeff Atwood’s rant on XML. It is a great article, and quite a treat from Mark’s usual concise style. I have deep respect for Mark’s technical skills and he has some very valid points about the true nature of XML. If anyone has seen the ups and downs of semantic tags, it is M. There is no specific piece that I can pick apart. Unfortunately, it is also wrong. Dead wrong.

Effective participation in standards bodies involves quite specific commitment and development of expertise, it is not a generic capability that can be instantly redeployed, Rumsfield-style, to trouble spots.

For example, while knowledge of OASIS procedures may help you understand some standards admin issues, it does not give any specific knowledge that can help understanding or predicting ISO procedures. Similarly, if you are an expert in implementing a word processor, that does not give you any specific knowledge of schema languages. And being an expert in a problem domain does not give you specific knowledge on different implementation/architectural strategies for schema language standards.

So what you end up with is say 10,000 standards committees each of which can benefit from 3 or 4 different kinds of expertise. If MS has 45 staff permanently working on particular standards, they may well be well-suited for a few dozen committees each, and may be able to skill up over a year to serve on a few hundred others. But that does not mean that MS, IBM or even governments necessarily have the ability to jump into SC34 WG 1 (or whatever) and instantly be effective.

The strange attack of modesty

Several bloggers have picked up the strange comment of Microsoft’s UK National Technology Officer McKee that it had little or no experience or expertise around software standards until the company was mid-way through the process of getting Office Open XML approved by the International Organization for Standardization. Andy Updegrove has a post (which is notable for actually agreeing with a point I made) and MS’ Matusow made a response too.

Can they all be true? Can MS be inexperienced (McKee), yet also be so big and active for such a long time (Updegrove)? And in how does Matusow’s comments that, no, MS is actually big and active for a long time actually counter Updegrove’s comments?

I think the problem is of merely talking about “standards participation” as if it were a generic commodity is the problem: Please buy 100 units of standards experience now! In fact, while certainly experience in one standards body gives a better grounding in how other standards bodies might work (compared to no experience), the devil may be in the details.

Mission-critical and multitudinous

Even within an organization, participation in one technical group (e.g. an JTC1 SC) might help in participation in another group from a procedural point-of-view, because typically standards work involves diving deep into the technical issues to the extent of being able to judge and suggest alternatives and new possibilities, it is very likely that a participant in one group is not a domain expert for the new group.

Furthermore, this is all compounded when you have international standards bodies: if the largest multinationals only have enough resources to commit one or two people globally to any area in the long-term, they certainly will not have the skills on tap. This is not only a problem for MS, but for all large companies; standards participation has not been seen as a revenue generator, nor has standards skills been seen as a mission-critical asset for high-tech corporations (or governments, for that matter.) (For example, I remember asking a Google honcho a couple of years ago what their standards commitment was, and being surprised to hear they didn’t have any at that stage; individuals could participate though.)

But standards are now mission-critical.

And they are vital to competition policy: for helping form markets from inchoate messes, for helping allowing broader stakeholder participation in oligopolistic markets, and for reducing barriers in dominated markets (see my blog All interface technologies by market dominators should be QA-ed, RAND-z (voluntary) standards for more on this.)

Expertise: contribution not domination

So the real story is something like there are many of the big high-tech firms have multiple people working on multiple standards at multiple standards bodies, but none of them have the expertise on tap that they can instantly have someone up-to-speed and participating effectively on any arbitrary standards group. And this is worst for national body participation and international standards participation.

But I don’t see why this is a bad thing.

While I certainly think all stakeholders should get their act together and participate, and develop experience, the last thing that standards groups need is invasion by non-technical suits making decisions on non-technical grounds, and the second-last thing needed is participation by technical people who do not have proper commitment from their corporate masters to commit to implementing the standards, however they come out.

After a decade and a half in standards work, I know and accept that the big companies blow hot and cold on standards bodies. (This is my “trap the bear when it is in the cage” argument.) They jump ship to the bodies that will give them the best result, they try to convince people that they jumped ship because the ship was rotten and not because they were rats, and they implement a standard only as far as it fits in with their development/marketing cycle, which often means minor version changes are not implemented, or that there can be periods of stagnation. Even the largest companies find it hard to stay on standards committees when they know they have no intention to implement that standards or its updates.

Increase in idealism then pragmatism

But we are seeing a sea-change in the attitude of regulators towards standards. Aware
that so much of the technical change of the last decade has ridden on the standardized
technologies, governments and regulators are increasingly likely to want to mandate standards; however, they then immediately discover that the standards processes of
all standards bodies in the IT area are not geared towards this being justifiable against
public policy: this has been an unintended consequence of the concerns expressed by many other stakeholders that OOXML was dominated by a single vendor (it turns out that most standards were contributed by single vendors or come from committees dominated by a handful of commercial players or from organizations with direct representation by vendors.)

Sensible stakeholders are taking the pragmatic view: encourage standards adoption but not prematurely or naively, penalize non-adoption of standards, and above all, participate.

The problem I saw in the OOXML (and the ODF) standardization at JTC1 was not so much that the large corporate stakeholders (MS, IBM, Google, etc) did not have resources on tap who knew about office formats (the domain areas) *and* SC34 technologies *and* JTC1 procedure *and* ISO editing *and* national body experience, but that there were so few other stakeholders involved who did.

Certainly I think all the corporate stakeholders should be involved more. And they should have assertive representation at OASIS, W3C, Unicode consortium, SC34 and the national bodies. But all stakeholders need to identify strategic standards and make sure they have the skill sets in place to be able to participate in the boring ongoing process of maintenance, not just the headline grabbing period. One of the good results of the OOXML standardization process is that more stakeholders have put their money where their mouths were, and started to participate at OASIS on ODF, as well as on OOXML.

Participation: babies are not freeloaders, non-participants are!

One of the great disappointments of the open source movement has been the way that lazy users don’t feed changes and improvements back, but are passive recipients. And often we see open source programs reflecting the priorities of its sponsors not its users. However, the standards process (when running correctly) have procedures in place to make sure that stakeholder comments will get looked at; but just like with open source there is an enormous intertia and laziness among stakeholders to participate.

The value proposition of open source and open standards, for many organizations, is that they get something for free, but that attitude ultimately means they get something sub-optimal for free. Organizations, and governments need to consider this very strongly, who have mission critical deployments or procurement programs based on open standards or open source need to assertively, pro-actively participate in the development and maintenance efforts of those programs.

There is a great quote (I’d have to track down who from: Dan Savage?) about gay couples holding hands in public: that to some extent in order to live in the world you want to you have act as if it were there rather than waiting for it to happen outside your actions. The same is true for standards: participation is essential.

[NOTE: this was previously posted to the OReilly DEV NEWS site by mistake.]

SwiXML is Wolf Paulus’ XML User Interface languge (XUI or XUL) which uses the regularity of the Java Swing GUI libraries to allow very lightweight implementation: XML elements are used for JComponents, XML attributes are used for properties (e.g. <frame size="5"/> would be JFrame.setSize(5)), and there is provision for layout managers, ids, custom JComponents and so on. Substance is Kiril Grouchnikov’s Look and Feel library for Swing components, which allows various subtle and lurid modern effects: the latest release, version 5, has just come out. Kiril has also written a good series of articles, available at his blog, on what he has learned about running a successful responsive open source project.

So, how can I use SwiXML with Substance 5?

Seelcting the look and feel with SwiXML is easy: you just add the appropriate plaf attribute to the top frame element. You can find a list of the various looks and feels available in Substance in the documentation or under the skin directory of the source tree. So your top element is, for example,

<frame  plaf="org.jvm.substance.skin.SubstanceOfficeBlue2007LookAndFeel" ...>
...
</frame>

In many cases, that is all that is needed. However, I found a gotcha with an easy fix.

In Swing, you are supposed to do everything concerned with the GUI in the Event Dispatching Thread (EDT). This prevents some kinds of thread-related problems, for example where one thread tries to access an object already destroyed by another. Some of the Substance code has checks, which generate errors if the function was not invoked in the EDT.

However, all the example code from SwiXML is run straight from the main thread. This is OK in theory because you are just initiating the object so there is no chance of mishap.

The simple answer is to run the SwiXML initialization in the EDT, and invokeLater() is our friend here. Instead of

   Component myGUI = new SwingEngine(this).render("xml/myGui.xml");

you use

  Component myGUI; 
  SwingUtilities.invokeLater(new Runnable() {
      public void run() {
        try {
           myGUI = new SwingEngine(this).render("xml/myGui.xml");
       } catch (Exception e) {
           e.printStackTrack():
      }
     }
   }
  Thread.yield();
  Thread.yield();

Unfortunately, even though Substance is highly configurable, it mainly uses various kinds of system or UIManager or rootNode properties rather than setters. It is possible to make a home-made property element in SwiXML , however because Swing elements are initialized before being attached to their parents, there is no way to access the client properties of the intended target object, so it is not well suited. (It seems you may be better of just specify the look and feel mix you want in Java rather than SwiXML at the current time.) But the simple selection of Substance LAF seems to work fine.

SwiXML already has support for the JGoodies Forms library built-in, which some of the Substance demos also use. I hope to get around to using the Flamingo library with SwiXML soon.

What are those Thread.yield() calls? The first is to make sure that the EDT thread runs immediately, just because we want to be in a good known state. The second is because it is possible, though not likely (though in Java who can say?), that Substance itself may use invokeLater() calls on the EDT where the runnable will be cued on the EDT but scheduled after the return from the first Thread.yield(). The second call is at least harmless, and perhaps best practice: some people think that just because in Java you often don’t have to think much about scheduling (or memory management) it means you never have to: quite wrong for desktop apps.

Firstly, I, like many of you, am glad to see that Dare Obasanjo’s indefinite hiatus from the blogosphere was short lived.

Secondly, while I most certainly agree with the premise of his recent “In Defense of XML” post — which was written in response to Jeff Atwood’s most recent attempt to get everyone in the XML communities of the world to hate him ;-) — the fact of the matter is:

Jeff Atwood is right!

Now before any of the members of the XML communities (of which I am a proud member of several!) pull out their pitchforks, and before any of the XML haters of the world declare some sort of moral victory, let me be perfectly clear:

So is Dare!

“WTF?” you say? Well, let’s first take a look at a portion of Dare’s argument:

CherryPy 3.1 is out and there are some exciting new features. The first exciting piece is the Web Site Process Bus. Robert Brewer had come up with an idea to create a generic server management API to help make management tools and libraries for Python servers standardized. Essentially, this is like WSGI for managing Python web servers. The next big feature is cherryd, which allows you easily run a CherryPy server as a daemon. Paste had a similar feature and it made managing Python web applications feel more like managing a tradtional web server. Also, the set of changes for CherryPy 3.1 make it possible to run CherryPy on Google’s App Engine. If you’ve never checked out CherryPy, take it for a spin. Congrats to Robert and the rest of the CherryPy team!