The beginning of the end of the pie-chart for business reporting?

Some thinking out loud about visualisation of business information in a Webby world. e-Pictures in the e-Enterprise.

XML Namespaces are a train wreck

interview with ERH on Artima. Quote:

Far and away the most common problem I've seen has been with namespaces. Namespaces are a real pain. They are difficult to understand. They are poorly designed. And a lot of the APIs that are out there either deliberately or accidentally try to pretend that namespaces are something other than what they actually are.

Yup. I've written about namespaces a couple of times recently. A study in XML culture and evolution attempts to tease out the cultural reasons for the differences of opinions over namespaces. This article XML namespaces explains the perils of lending money to a certain sort of person :-).

ssh into the matrix

I did the whole Matrix Reloaded thing last night. I could have done with less of the silly fighting scenes and more of the amazing car/bike chasing, but hey, when I was a kid we watched Bruce Lee.
The DVD would merit some freeze frame analysis. I spotted SSH at one stage being used to log into a power grid.Somewhat disappointed to see that "the source" is a freaking mainframe. Surely that should be a billion node Linux cluster?

Jon Udell

"The inexorable logic of Web services sets aside APIs in favor of protocols. XML messages flowing through the pipes enact those protocols."

Amen to that. You know the hardest thing for a lot of programming folk to grasp about Web Services is? Its not about APIs. Forget APIs. Forget RPC. Forget SOAP. If you are thinking APIs you are going in the wrong direction. Thing *documents*. Think documents flowing. Think reliable messaging. Think XML transformations. Think URIs. Think HTTP POST and GET. Think design by contract (where XML schemata are the contracts). Think message choreography. Think two-pin in/out interfaces. Think plug-replaceable components that communicate solely via XML messages. Think loose coupling. See?

SOAs to zap the integration problem in a couple of years - too optimistic but on the right track

[Via Loosely Coupled]. A Techweb story about how SOAs will dramatically reduce integration costs over the course of a couple of years.
I'm a true believer in SOA's but that timescale is way too optimistic. Even in a perfect world where SOAs are implemented as they should be architecturally, this is optimisic.
Evidence is already mounting of a blind alley some implementors are going down in implementing SOAs. Hint - if your nascent SOA architecture diagram consists of blocks, layers, RPCs and APIs - its not an SOA (to my definition!).
If your architecture diagram has flow (often notated by circles, ellipses and pipes), synch-over-asynch MOM, XML transformations and input/output XML documents with associated schemas (service contracts) then you are on the right track.

If an XML document has a doctype - is it an XML document?

An intriguing XML validation proxy but see this:

"XML containing DOCTYPE declarations are blocked."

Now don't get me wrong. I'm a fan of eliding DOCTYPE declarations from XML instances in favour of specifying a schema (DTD, RNG or (blech)XSD) out of band. I've been advocated this for years.
But also years ago I was part of an effort to create a profile of XML that stripped out things like DOCTYPE (Common XML. We got eviscirated for using the word "XML" and for diluting the brand name.
As if "XML" has a clear meaning. As if "XML tools" is defined in any real sense. It isn't.
XML is is lune on the noosphere not a point on the noosphere as we would perhaps like to pretend.

The trouble with RDF

Tim Bray on RDF

"At this point, the RDF evangelists pipe up and say “Well, Ordinary People (tm) don't have to look at the source, there will be tools to sort all that out.” Sorry, I just don't believe that. If, in 1994, you'd needed DreamWeaver or equivalent to write for the Web, there wouldn't be a Web today."

Amen. I *hate* the tools-will-do-it argument - not only for RDF but for all software. The argument is a breeding ground for complexity. It lets people off the hook (you don't need to take the time to be brief, you don't need to simplify.). It lets vendors off the hook ("X is complicated but we will flog you funky tools to manage the complexity").
A lot of XML technologies these days are big bags of complexity. A lot of it comes from this idea that XML is not meant to be read by humans. As soon as you say that, you are on the slippery slope in my opinion. Tim (Bray's) RPV notation shows that the RDF model does not have to be ugly when serialized. Same goes for Tim (Berners Lee's) N3 notation.
Syntax matters - that is all ye know on Earth and all ye need to know.