A critical point about standards

Jon Udell asks a key question that cuts to the heart of what standards really are and the relationship between notations and process models.

A standardised notation is a good thing but it can only go so far in specifiying in abstract language the intended processing model of systems consuming the notation.

The "definition of correctness" is an escalator that starts with notation, proceeds up to test suite and from there - more often than not - to reference implementation.

What does it mean for a Python program to be "correct"? Is it in the specs, the test suite or the reference implementation?

Sometimes you just need the specs. /etc/passwd on Unix is too simple to need a processing model or even a test suite probably. What about HTTP Headers?, RTF? XHTML?, ODF?

The reference implementation issue becomes critical when the processing logic gets complex *or* when the definition of correctness transcends the reach of the computer into human-space such as sight or sound. Sight in particular is key. "Does it look right" is not a question that computers are good at answering. This is why, I believe, visual systems like word processors and web browers benefit from reference implementations.

The system fails to be open of course, the moment the reference implementation fails to be open. Regardless of how much XML is sprinkled over it.

Test Suite for ODF specs.

A Test Suite for ODF compliments of Intel.

Oops

Jorn Barger has pointed out that my choice of example in this weeks ITWorld article is not a good one.

Apparently, the "pre-raphaelite's" did run around with that moniker in their heads.

thanks, John.

Sean

Blank metadata fields in content management systems

"...One year later, most of the metadata fields for new content are found to be either blank or wrong, consisting of convenient dummy values to get the content management system to stop beeping. Much scratching of heads and nursing of sore wallets ensues.

And now for my theory...."-- Hysteresis, History and empty metadata fields

Heuston, we have a website

The Python home page has had a serious revamp. Looks very nice. The NASA story top right is pretty eye-catching.

ODF Toolkits

David Berlind asks where are the ODF developer kits.

I guess it depends on what you want to do but for my money, there are lots of ODF developer kits out there. They are called XML processing toolkits:-) Ok, I'm being a wee bit cheektongued when I say that.

We do a lot of ODF processing and, where possible, we do it in XML processing pipelines that are outside of ODF itself. We use Jython for most of this heavy lifting, ODF munging work.

When it comes to working interactively with OOo, our preferred method is PyUNO. Using Python for inside OOo work and outside OOo work minimises the seams between the two activities.

For deep integration of OOo into custom applications, there are a number of options ranging from headless execution through to OfficeBeans. Somebody even did an ActiveX control if memory serves me right :-)

There is also the VB-like scripting language that ships with OOo itself.

Now I'm a bits-on-the-wire kind of guy so I like my XML served up straight. I'm not a fan of endless abstractions that hide the "complexity" of text and thus not a great fan of APIs for applications that are fundamentally about text.

I fully realise that not everyone thinks the way I do and people see complexity in different places and prefer to deal with it in different places.

So, my perception of the state of the OOo developer kit landscape is skewed to my way of thinking and from my viewpoint, things ain't too bad.

Sky TV - not-quite opaque identifiers - vexation

So, yesterday Sky TV decided that BBC1 is no longer 169 and the Arts Channel is no longer 157 etc. etc. etc.

The numbers of channels in Sky's layout are not as opaque as wonks like my would prefer. And there sure ain't long lived as yesterday proved.

My guess is that the big re-org is to make way for all the scrumptious HDTV variants. They may also have been pressure on the semantic banding : 300 for movies. 400 for sport that sort of thing.

So here is the upshot: (1) embuing numbers with semantics (especially allocating ranges) will bite you one day. (2) If you don't embue numbers with semantics (such as allocating ranges) you are safe but don't have many customers because customers want identifiers to be less-than opaque.

Simple to use with an occasional earthquake renumbering beats harder to use with no earthquakes.

Apparently.