Rescuing Nokia

The Register writes about Rescuing Nokia. The story originates from a book (promo site in Finnish) written by an old Nokia insider, Juhani Risku.

According to Juhani, Nokia has become fat, heavy with middle management bureaucracy which hinders creativity. The seed of the problem stems, according to Juhani, from incompetence of the leaders.

Amongst some of the most interesting things, the article mentions that Nokia had already been working with touch screens ten years ago, but abandoned development. Many other innovations were ready to be developed to products many years ago, but Nokia more or less ignored them, watching competition implement the features many years later. Often, it was a case of complete lack of ability to move innovations to production due to the massive and crippling effect of incompetent middle management and division leaders who had no real experience in the matters.

Juhani also states that American style business management built around short sighted arrogance and greed has hindered innovation. According to him, appointing a CEO from the USA would be a big mistake and another delay for a company that is Finnish down to the core. American style management just does not work.

XML Schema Design Links

Here are my definite sources for XML Schema Design:

Zero, One, or Many Namespaces?
W3C XML Schema: DOs and DON'Ts (Kohsuke)
Reference Model For XML Design (PDF)
W3C XML Schema Design Patterns: Avoiding Complexity (Obasanjo)

These all represent slightly different viewpoints.

For example, these are Obasanjo's guidelines altered from Kohsuke's:

I've altered some of Kohsuke's original guidelines:

• Do use element declarations, attribute groups, model groups, and simple types.
• Do use XML namespaces as much as possible. Learn the correct way to use them.
• Do not try to be a master of XML Schema. It would take months.
• Do not use complex types and attribute declarations.
• Do not use notations
• Do not use local declarations.
• Do not carefully use substitution groups.
• Do not carefully use a schema without the targetNamespace attribute (aka chameleon schema.)

I propose some additional guidelines as well:

• Do favor key/keyref/unique over ID/IDREF for identity constraints.
• Do not use default or fixed values especially for types of xs:QName.
• Do not use type or group redefinition.
• Do use restriction and extension of simple types.
• Do use extension of complex types.
• Do carefully use restriction of complex types.
• Do carefully use abstract types.
• Do use elementFormDefault set to qualified and attributeFormDefault set to unqualified.
• Do use wildcards to provide well defined points of extensibility.

There are still some problems with extensions of complex types and validation. The problem is the need to have xsi:type attributes sprinkled in your XML documents. From a purist point of view, we should not really have validation artifacts in our XML tags.