One of the latest white house dispatches changes the order of succession should the secretary of defense become incapacitated or dead.

Here's the new lineup:

a) Deputy Secretary of Defense;
(b) Under Secretary of Defense for Intelligence;
(c) Under Secretary of Defense for Policy;
(d) Under Secretary of Defense for Acquisition, Technology, and Logistics;
(e) Secretary of the Army;
(f) Secretary of the Air Force;
(g) Secretary of the Navy;
(h) Under Secretary of Defense for Personnel and Readiness and the Under Secretary of Defense (Comptroller);
(i) Deputy Under Secretary of Defense for Acquisition and Technology, Deputy Under Secretary of Defense for Policy, and Deputy Under Secretary of Defense for Personnel and Readiness;
(j) General Counsel of the Department of Defense, the Assistant Secretaries of Defense, and the Director of Operational Test and Evaluation;
(k) Deputy Under Secretary of Defense for Logistics and Material Readiness and the Director of Defense Research and Engineering;
(l) Under Secretaries of the Army, the Navy, and the Air Force; and
(m) Assistant Secretaries of the Army, the Navy, and the Air Force, and General Counsels of the Army, the Navy, and the Air Force.

For comparison, here's the old lineup:

(1) Deputy Secretary of Defense.
(2) Secretary of the Army.
(3) Secretary of the Navy.
(4) Secretary of the Air Force.
(5) Under Secretary of Defense for Acquisition and Technology.
(6) Under Secretary of Defense for Policy.
(7) Under Secretary of Defense (Comptroller).
(8) Under Secretary of Defense for Personnel and Readiness.
(9) Deputy Under Secretary of Defense for Acquisition and Technology.
(10) Deputy Under Secretary of Defense for Policy.
(11) Director of Defense Research and Engineering.
(12) The Assistant Secretaries of Defense, the Director of Operational Test and Evaluation, and the General Counsel of the Department of Defense, in the order fixed by their length of service as permanent appointees in such positions.
(13) Under Secretaries of the Army, the Navy, and the Air Force, in the order fixed by their length of service as permanent appointees in such positions.
(14) Assistant Secretaries of the Army, the Navy, and the Air Force whose appointments are vested in the President, and General Counsels of the Army, the Navy, and the Air Force, in the order fixed by their length of service as permanent appointees in such positions.

That's a pretty major shakeup. Hope Rumsfield stays healthy. Oh, and the 'old lineup' is before June 2005. For the last six months the president ordered that Rumsfield be followed by the Secretary of the Navy. Period. Who's the navy sec? what happened in June to make the president make this change? Who's the SDI? It's all pretty weird. Smells like a power struggle.

Yesterday was the first time I broke a sales record on the upside since about March 2002, when I had been in business three months. The big difference is that I'm now selling stuff way below cost.

Bargain hunters. They're a very rude sort of people. I don't particularly like them as customers because they're the human equivalent of vultures. They go on a feeding frenzy whenever somebody sells at a loss (or finds some other way to offer prices lower than anybody else on the planet for a particular item). They mob in and pick apart any good meat and leave the useless scraps for whatever rodents might follow. I might mention that this is a very predictable form of behaviour and the large chain stores are built around this model of shopping.

We're living in a vulture economy. That's scary.

Turns out there are several folks working on rails-like functionality for PHP. I've looked at them. Sort of leaning towards 'cakePHP'. Only because it's got four or five people using it. The others have one or two. It isn't as many folks as are using ruby||rails by far. The advantage is - code re-use. I mentioned that programmers are lazy. We don't like to do the same things over and over. Re-writing what we've done in another language is even worse than re-writing it because just like human languages, something always gets lost in translation.

Anyway, back to cake for a minute. For programming web apps on top of a database, there's no turning back to the old days. This is so much faster. It's well organized. And if you don't like how it's organized you can change it. Name your project and create a schema. You have to do these things anyway. But with the new tools, this is all you have to do in order to provide basic functionality. It's called CRUD - create, read, update, delete - all from a web page. Once you name your project and define the schema, you've got CRUD. Can't think how many times I've re-written this part to deal with a changed schema. With the application architecture, you don't have to. It's already there. You've also got more. It's an application architecture. There are three layers, and they all have different code pages. One layer talks to the database and other physical resources. A middle layer contains what we call business logic. That's really the secret sauce for the application. The top layer is presentation. HTML, XML, text, whatever.

Unlike the old days, the secret sauce and database logic are removed from the file that gets changed the most - the presentation layer. We're always tweaking how a page looks. We tweak the way it works less often. We tweak the way it accesses data even less than that.

Got ruby (and the rails) installed and working and I've been doing my typical computer dialect quick learn. There was a language before that claimed to do things in less lines of code than what we were using before. It was called PERL. I don't use PERL anymore unless I have to. It is one of the most horrid language specifications I've ever seen.

Ruby looks pretty nice, but it's a bit obtuse. If you're a C or PHP or whatever programmer, you can't exactly read it without a reference nearby. You can read it, but there are a lot of subtle punctuations. I hate subtle punctuations. Yes, they make for a more powerful language, but they also make for subtle bugs. For instance,
  scaffold :event
is a valid statement, but
  scaffold : event
is not.You also apparantly cannot have a database table named 'date' because creating a 'date' class to access it will throw all kinds of errors. It collides with the existing date class which manipulates date information. Of course I have an existing database called 'date' that I cannot use with Ruby||Rails because of this. Sigh. I hate database conversions. I'll have to also change the other application which is using the date database. I made all of these discoveries within ten minutes of getting ruby working.

Looks like it's a wonderful language for discovery of how subtle things affect how the program runs. Perl was likewise a wonderful language for discovery. That's why I don't use it anymore.

We'll see. I use languages that make my work easier. The claim is that Ruby makes my work easier. I'll give it the benefit of the doubt until proven otherwise. But my initial impression is that it's destined to be a flash in the pan like java. Remember when everybody was programming in java? Where are they today?

It also wouldn't take much to put a database and view abstraction layer on PHP. Hint, hint.

One more reason to dump the iTunes DTD... it doesn't exist anymore! Observe the following RSS+XML feed:

<?xml version="1.0" encoding="iso-8859-1" ?>
<rss version="2.0" xmlns:itunes="http://www.itunes.com/DTDs/Podcast-1.0.DTD" >

The 'xmlns' declaration is supposed to give a 'dictionary' of the document language so that an absolute stranger to the itunes namespace can figure it out. I'd have to go dig up the xml spec, but I'm pretty certain they say in pretty strong language that if you sponsor a DTD, you kinda' gotta' haveta' put it at a URL that is never going to change. Ever. This URL comes straight from Apple's own Podcast spec (which coincidentally was invented by MTV veejay Adam Curry, who will soon be the father of the internet according to wikipedia).

Yet if you go to that web address and try and read the language definition, you'll find yourself instead at apple.com/itunes staring at an Apple eShopping mall and in my case telling me that I need a new operating system to install iTunes. Where's the DTD? In fact I'm just trying to extend RSS in another way and was going to use their DTD document as a template (since it's about the only existing extension onto the RSS space). Sigh...

As I've delved into the deepest pits of extending the eXtensible Markup Language (XML), I've found that it has been over-engineered to the point of absurdity. DOCTYPE's, DTD's, XSLT's, RDF, etc.

It's enough to drive an insane person crazy. Extensible? Try it sometime. You've no idea the can of worms you'll open. I think it's time to dispense with the whole mess and get back to what XML started out as. A means to convey information through a '<tag>content</tag>' syntax.

It is an implicit format to allow producers and consumers of information to talk the same language. In doing so, all of the information forms have been forced to be standardized so that the information language is discoverable through namespace declarations and associated style guides.

Why bother?

It's all well and good for something like a web browser which needs to display information, but it's overkill for the use of XML as a simple data exchange format. All you really need is for an information consumer to recognize an element that it knows about and deal with it.

So I'm proposing something new. FreeXML. A freeXML document can look just like an XML document. The only difference is that it doesn't care what it is presented with. Either it recognizes the data or it doesn't. Namespace declarations? We don't need no steenkin' namespaces.

<freeXML>
<html>
<head><title>a freeXML document which contains HTML</title></head>
<body>
Anybody can do it. See?
</body>
</html>
</freeXML>

Now let's go a step further -

<freeXML>
<animals>
<item><name>dog</name></item>
<item><name>cat</name></item>
</animals>
</freeXML>

Either you know what an 'animals' is and how to deal with it or you don't and you ignore it. This is what every XML consumer does now. The only difference is - No DOCTYPE, no namespace declarations with associated DTD, no XSLT. Either the information consumer can handle the data the producer produces, or it can't.

What about extensibility? What about it...

<freeXML>
<animals>
<item><name>dog</name><mypetname>Fido</mypetname></item>
<item><name>cat</name><mypetname>Fluffy</mypetname></item>
</animals>
</freeXML>

Again, either you know how to deal with <mypetname> or you don't. Validation? Why? If you've grabbed this 'animals feed' from a remote source and don't understand a particular element, it wasn't meant for you, and you can ignore it.

What can you do with freeXML? Anything you can do with XML. It's just another type of markup. Heck, you can embed XML into freeXML. Here's an RSS feed -

<freeXML>
<xml>
<?xml version="1.0" encoding="iso-8859-1" ?>
<rss version="2.0" >
<channel>
<language>en-us</language>
<title>Diary and Other Rantings</title>
<description>Life in Silicon Valley by a former software engineer who now runs a music store.</description>
<link>http://macgirvin.com/blog</link>
<lastBuildDate>Mon, 19 Dec 2005 11:57:51 -0800</lastBuildDate>
<generator>Note-a-Day Weblog - Version 2.2</generator>
<copyright>Copyright 2005 Mike Macgirvin</copyright>
<webMaster>mike@macgirvin.com (Mike Macgirvin)</webMaster>
<managingEditor>mike@macgirvin.com (Mike Macgirvin)</managingEditor>

<item>
<pubDate>Sat, 17 Dec 2005 12:00:00 -0800</pubDate>
<title>Goodbye, Ruby Tuesday..</title>
<description>Who could hang a name on you?&lt;p /&gt;Actually, the name is &apos;Ruby on Rails&apos;. It&apos;s quite an interesting moniker for a programming language. OK, the language is Ruby. The &apos;on rails&apos; part has to do with adding the programming language with database classes into a web server&amp;nbsp; and database environment. The example is an entire web-based recipe database in one line of code. That&apos;s impressive, and it&apos;s attracting a lot of attention. It was only a matter of time. Programmers are lazy folks. We don&apos;t like to write the same things over and over. So every time a new language pops up that includes more and more of the stuff that we&apos;ve written over and over again, it&apos;s bound to take off. &lt;p /&gt;But if you look under the hood, it&apos;s not quite one line of code to write a web based recipe database. In fact the tutorial takes three pages of system configuration and database mucking before you get to the one line of code. Some things never change. &lt;br /&gt;</description>
<link>http://macgirvin.com/blog/index.php/DEC-2005#article-17-DEC-2005</link>
<guid isPermaLink="true">http://macgirvin.com/blog/article.php?17-DEC-2005</guid>
<comments>http://macgirvin.com/blog/feedback.php?17-DEC-2005</comments>
<category>software</category>
</item>
</channel>
</rss>
</xml>
</freeXML>

First customer:

Do you have any guitar picks?

Yeah, right over here.

How much are they?

Twenty five cents each.

You have anything cheaper?

Nope.

OK. I take one.

Thanks, next?

Glokpee kwaidong?

'Scuse me...?

Glokpee kwaidong?

I'm not sure... Could you point to something?

Glokpee kwaidong bakwtui!

I'm sorry, but I'm all out of glokpee kwaidongs right now. Next?

My violin won't stay in tune, can you help me?

Sure. (I tune it up without any difficulty). Seems to work just fine.

What are those pegs for?

Those are for tuning the violin. You need to adjust them to keep it in tune.

Really? My teacher never told me that.

Next?

Glokpee kwaidong?

I think your wife was here a few minutes ago. She went that way... Next?

You had a new flute in your window for $9.95 about six months ago. I'd like one.

That was a closeout special. It's long gone.

When you get more?

Never. Next?

And so it goes...

It's hard to believe that it was only a week or two ago that I was extolling the virtues of the Drupal CMS. So much has changed since then. If you recall, I made it sort of work for my needs after fixing a lot of bugs. I was all set to contribute my fixes back to the Drupal development community. But then something happened. They released a new version. Cool! I thought. I'll just download it and get all the latest stuff and maybe they've fixed some of the bugs I uncovered. Doesn't work that way. More bugs. Things that I spent time fixing are now hopelessly broken. The fixes I made can't be applied to the new code. It's all different. And Drupal works on a 'module' framework. They only provide a core application, and others in the community add things to make it do more stuff. The problem is that every time they change the core, they make it incompatible with the existing modules. Nothing I added works anymore. I have to wait for all the different modules which I was using to be re-written. Or do it myself. No thanks. They have a nasty habit of making every existing contributed module break on every version release. So you can't just write a module or fix a module and be done with it. Writing a module makes you a lifetime contributor. You'll have to fix the module over and over again and over again and over again - everytime the core application changes. Looking at the development roadmap, this is going to happen a lot. Think I'll go find another CMS package.

Or see if I can write one in Ruby||Rails in a dozen lines of code... 

Who could hang a name on you?

Actually, the name is 'Ruby on Rails'. It's quite an interesting moniker for a programming language. OK, the language is Ruby. The 'on rails' part has to do with adding the programming language with database classes into a web server  and database environment. The example is an entire web-based recipe database in one line of code. That's impressive, and it's attracting a lot of attention. It was only a matter of time. Programmers are lazy folks. We don't like to write the same things over and over. So every time a new language pops up that includes more and more of the stuff that we've written over and over again, it's bound to take off.

But if you look under the hood, it's not quite one line of code to write a web based recipe database. In fact the tutorial takes three pages of system configuration and database mucking before you get to the one line of code. Some things never change.

For decades it has been believed that the first peoples to populate North and South America crossed over from Siberia by way of the Bering Strait on a land-ice bridge.

However, a new study examining the largest collection of South American skulls ever assembled suggests that a different population may have crossed the bridge to the New World 3,000 years before those Siberians.

People with skulls resembling Paleo-Indians were present in Asia around 20,000 years ago, and lacking the technology to cross the Pacific Ocean by boat, they probably crossed the land bridge to Alaska several thousand years before the Siberians, said study co-author Mark Hubbe of the Universidade de So Paulo.

"We don't know for sure, but we believe at least 3,000 years earlier," Hubbe told LiveScience. "We have a difference of 3,000 years in South America, and we can assume the difference is the same in North America."

--

This is being presented to the Journal of the National Acadamy of Sciences. I do not call it science however. My first skepticism is in the part 'they probably crossed the land bridge...' which is based entirely on the belief that people lacked the technology to cross an ocean 10,000 years ago. Throw a big tree into the water and it will cross the ocean. People 10,000 years ago couldn't sit on a floating log? It was too advanced for their primitive brains? Really?

My next issue is pretty plain, in the last paragraph. "We can assume...". Right. That's not science. admittedly I'm one of a small handful of people who have found the evidence to be overwhelming that cultures had come and gone in the western hemisphere long before the great Asian migration of the last ice age. There was humanoid acitivity all over the western slopes of the Andes - long before the Bering crossing. Bolivia, Peru, Chile.  During this time, huge megalithic stone structures appeared all over the planet, including these places.  Most 'scientists' refuse to acknowledge this body of evidence, clinging to beliefs and assumptions about what technologies humans had available prior to written history. We simply don't know.

But I am excited by the fact that we have yet more overwhelming evidence to consider once we get some real scientists to put all the pieces together and tell us what really happened.

Mr. Williams was executed.

I've long since given up taking sides in the death penalty debate. I will only comment on the absurdity of the twenty-four years that elapsed since the sentence was issued. I think it would be a fascinating statistic to see how many death row inmates in the US have actually died of old age.

Something that has really been starting to intrigue me is the potential for wanton internet identity theft. It works like this... you go to a cool new site and sign up with a username and password. Just like the other hundreds of sites you belong to. But unless the site has imposed a particular username on you (your first choice was already in use), aren't you going to use your 'standard login'? Same thing on Amazon, Google, eBay and everywhere else? Don't lie. Everybody does. And that's why it is interesting.

What about on stinkinidiotsinweirdclothes.com ? Wouldn't you use your standard login there as well? If you're like most people, of course you would. Do you know who has access to the database? Do you trust him/her/them? One well-placed internet site could collect thousands of logins. Every one of them would probably be good on 10-100 major sites and thousands of smaller ones. Credit cards, shopping, bank accounts. It's probably a hundred times as effective as a phishing scam.

Now that you're aware of the problem, what can you do about it? Start changing your passwords! Change something - anything. (Perhaps) add the first character of the site name into your standard password. The only thing that's preventing this from being a global crisis is that nobody has sufficiently exploited it for personal gain (yet).

Over in the XML playground I've been quite busy. Dang. I've fixed a lot of bugs. Really nasty mostly simply obvious bugs. Who's doing the QA for this thing? Oh that's right. Free software. Looks like I'm doing the QA - and fixing everything the young whippersnappers didn't learn in CS-101.

The next piece (which is probably going to take a few days) is to re-do the XML aggregator so that it supports something called 'My Feeds'. It's almost there, but not quite. It will already let folks administer XML resources, but they can only view a) an individual feed, or b) the whole universe. I want everybody to be able to build their own data streams.

You've no idea how pathetic is the state of the vast universe of XML feeds. Most of the sites that I'd like to get a feed from don't offer one, or they only offer teasers (a headline followed by 'go to the site to read the story'). That's hardly an information feed. Several overseas sources I tried are using Windows code page 1215 as their XML charset. Yuck. I don't have a UTF-8 convertor for that one. I also can't seem to load any Wordpress sites where somebody used an ampersand or tag element in their category name. Wasn't properly XML escaped. (Note to self: check my own code - I don't think mine escapes these either). So there you have it. For every ten potential feeds I've looked at, only one or two converse in a compatible XML dialect. Of those, only a small fraction offer any meaningful content.

During the last few months I've been installing and evaluating a bunch of the public domain Content Management Systems. I've mentioned previously that I'm not particularly impressed by them. They're pretty much geared towards idiots that want to launch full-featured websites. As a consequence they need to make every aspect of running a web portal appeal to the masses. So they can't call something 'keywords' or 'categories' - instead it's 'taxonomy'. Because 'taxonomy' is more understandable by the average human than 'keywords' or 'categories'. Right. On four out of five of these packages it took an hour of searching menus to find a place to set the site title. Free software. You get what you pay for.

But I found one that wasn't too bad. It's called 'Drupal'. It's got some bugs and quirks, and is similiarly obtuse, but it seems to do quite a bit. So I loaded it up over on the floozee site (that's dot com, hint hint).   Multiple blogs, discussion boards, event calendar, newsfeeds, buddylists, etc. Pretty nice little app (once I fixed a few bugs). Oh, and it's got a crude but functional XMLRPC interface. I would have said that it's the perfect launching pad for my next great blog idea - except that it pretty much embodies my entire next great blog idea. I've got some configuration work to do, but basically you build a community blog portal that's tied to an event calendar, latest newsfeeds, online discussion groups, etc. Sigh... guess it wan't such an original idea after all. But now I've got a framework with all the right code to do what I was thinking, so maybe I'll figure out a unique twist yet.

Having a cup while the operating system is being restored on the system that failed yesterday...

Yet another group of folks is scheduled to come out today and gaze at the bubbling brook outside my store and figure out if there's anything they can do about it. The first guys, at great expense - are going to run a series of high-tech tests to figure out where to dig.  The second group might actually start the excavation.

I looked at the dysfunctional hard drive. Western Digital. Gak... Let me tell you something. I've got a drawer full of old hard drives. Some of them go back twenty years. Every single Western Digital drive I've ever owned has failed,  and almost always have failed spectacularly. Most every other drive I've still got, and I can still access them given the right hardware. Draw your own conclusions.

2:00 PM

The operating system has been reloaded. Restored my most critical applications first. First things first... the printer drivers and the web browser. Then use the browser to grab the backups. The rental accounts recovered flawlessly. Then I open my financial account data. The most recent date on record is 2003. Ouch. Two years of lost data. Including this year. But I just backed up this two days ago. How could that be? Perhaps I loaded the wrong backup. I scanned the server directories. There's a problem... I have two versions of the backup on the Unix box. In one, the file extension is lower case. The other is upper case. And it was created two days ago. So I reloaded with the upper case version of the file.

The newest date is still 2003. Now I'm starting to sweat. My finances for the entire year - I don't seem to have them on backup. I check the other server. There's a file from Jan-2005. OK - let me try that one. I'll at least have a little more data than I do now. But I think the bank will only let you download three months into the past. I've still got a big problem. Doesn't look like there's any way to recover most of this year. I'm really sweating now. So I load the file from January. The newest date is still 2003. You'd think I'd be sweating buckets, wouldn't you? But no. Now I breathe a sigh of relief.

You see, I've used that particular backup before (the one from January). I know that it contains more recent information than 2003. The program migrated the data on the first file I used, and stored it somewhere else. It didn't even look at the two other backups I loaded.

So I deleted all the data from the program, and started fresh with the uppercase file from two day's ago. Bingo. Everything is there. Sync with the bank and everything is hunky-dory.

They found the leak. I've got jackhammers going 30 feet from me right now. Should be fixed in another hour. Glad it was outside the store...

 

Boy don't you hate seeing that message? Especially when the computer is making loud clunking noises. It's the book-keeping computer (again). All my business accounts. Guess that's what I get for buying Fry's cheap house brand. So when's the last time I did a backup? Yesterday at 5:21 PM. Phew! That was close... Still this means re-installing an operating system and all my necessary applications. 

Or even when it doesn't rain. There's a puddle of water outside the shoppe. First noticed it a couple of days ago. That's odd. Everything else is dry. How did it get here? Then today I looked closer and noticed that the water was actually bubbling out of a crack in the concrete sidewalk. Uh oh. Broken water line. Right outside the front door of my business. Somebody is going to have to fix it. That means that the sidewalk and tile entry to my store is going to have to be dug up. Can you imagine trying to sell a business while the entryway is being excavated? I doubt you can find this tile anymore - it dates from the thirties. As in nineteen-thirties. They'll probably need to have the water shut off while they're working on it. Which means I'll probably have to close the doors while they're working on it. During Xmas shopping season. My brain is aching from just trying to imagine all the implications. Wonder how long I can go before alerting anybody that this is even happening...

Update:

Of course the situation would get worse. I discovered that it isn't just bubbling water outside the building, my front window 'bay' is flooded as well. Damaged a couple of cellos. So I contacted the landlord's representative. The landlady died last month. The person who inherited the building is in Arizona. The representative told me to call the city.

The city maintenance crew came out. They won't touch it. It's not their problem. So I called the rep again. He got the local Roto-Rooter guy to come out and look. Hmmm, this is going to be a lot of jackhammering. The sidewalk has to go. The front of my building might have to go also. They're not going to touch it. Nobody apparently is going to take any responsibility. I'm stuck in the middle. The front of my business is flooded and nobody is going to fix it. The landlord's rep is claiming that it's my responsibility. But I don't have any authority (not to mention resources) to ask somebody to jackhammer the public sidewalk on Main Street and excavate beneath the front of my store. It's also not my building. I share it with two other businesses. Sigh... Any way you look at it, it's a disaster.

Finally got some XML sources to talk XMLRPC to each other. As I mentioned on a prior occassion, this is distributed computing made easy. So why did this take so much time? It's software. Software is not easy. Software communication is even harder. First you need two different systems that even have the ability to converse with each other. Then you need to get them talking the same language. What is system A expecting to hear? What is system B saying? Now reverse the roles and try again. Analyze every byte of every conversation to find the source of the failure to communicate seemlessly. Finally found it. Was sending RSS items to one server, who only wanted  the elements of the item, not the items themselves. Grrr. Then the XML generator was double escaping  XML entities.  Fixed that. Then all of a sudden it started working. Great. I can edit my weblog and have it propogate to any place on the web that I might wish to have a weblog. That's what's cool about XMLRPC. And it's only the beginning. The proof of concept has been around for a few years now. But folks like me are just starting to actually use it. And the API's are still primitive. Let's take the weblog example. If I decide to update 20 weblogs from one page - I have to keep track of

• where each weblog resides
• my login credentials for each weblog
• the unique name of the weblog that I wish to edit
• for every message : the message-ID of that message for that server
• the category list for every server
• yada, yada

It's too much data to have to enter and keep track of. That's why using XMLRPC as a weblog tool won't survive except on systems with huge databases or as a remote data entry tool for one blog. But that's where XMLRPC came from. Proof of concept but less than a must have. It isn't where XMLRPC is going. It's a must have, but only after we get the infrastructure in place.

I've had about enough of the iTunes XML namespace DTD. Think I'll yank support from my codebase. Originally I thought it would be nice to be able to provide Apple compliant podcasts. But whoever came up with this DTD should be drawn and quartered. If you've been following the furor over podcasts over at Wiki, I think we'll probably find that Adam Curry invented this DTD. If you haven't been following - here's how it goes. Somebody has been editing all the references to podcasting on wikipedia. They've been over time removing reference to every name on the page except for Adam Curry. All the developers who actually made it work. Now here is where it gets interesting - all of these edits have originated from IP addresses that are owned or controlled by Mr. Curry.

But I digress. It's the DTD that I'm ranting about. They've got an element called <itunes:duration> - which gives the play length of a sound file. This is a wonderful thing to have on a podcast because the RSS spec only supplies the size of a media attachment in bytes; not in play length. But why - oh - why is <itunes:duration> an element of <item>, which is a description of an article ? It should be an element of <enclosure> - which is the data it describes. The problem arises if you have two such enclosures. Which playlength belongs to which file?

Turns out that this is only one issue with the iTunes DTD. There are hundreds more. After all, it wasn't designed to be a web standard. It was designed quickly as a means to sell Apple products, and coincidentally is a perfect one-to-one match for the iTunes.com database schema. Think I'll wait for a better attachment DTD to come along.

I've been out of contact while coming to grips with the business situation. Any hopes for a holiday boost in sales have been dashed. Yet another worst month on record. Less than half the sales of the previous worst month on record (last month). It's way beyond being a desperate situation. Didn't even cover a significant fraction of operating costs this month. Can't afford to buy even one set of bongo drums for the handful of Christmas shoppers I might get later in the month.

Game over.