Rael Dornfest has some observations on why Open Source
projects are able to make decisions online whereas other areas seem
less able to do so. This complements my A Bias for
Action post. A follow up to that post: Jim
Jagielski thought I had added some cool additons.
Ask Bjørn Hansen
apparently wasn't satisfied, so he refactored it a
bit. From the comments at the top of the new source file:
# Original version by Sam Ruby, written in Python.
# Ported to Perl, and enhanced by Jim Jagielski
# Enhanced to have links to personal pages by Sam Ruby.
# Enhanced to have the code suck less by Ask Bjoern
Hansen.
Gotta love it!
Phil
Ringnalda. Even though I can hear Sam muttering digital
magpie in my ear... Phil, you say this like it is a bad
thing. 
I believe that you and I have common tendencies when it
comes to exploration, but when it comes to choices, I find that I
have a tendency to pick the dull and boring ones.
As to the topic of blog browsers, I do have a number of
thoughts. One set of thoughts is that the data being
captured is not merely hierarchical, it is actually
hierarchical faceted metadata. But mostly my thoughts are
to the dull and boring topics of the file format itself.
For starters, my site is generated dynamically. This means
that you can see any blog entry, day, month, or year in any of
several formats. Here's August
in rss2. June
11th in txt. Entries
containg "Ringnalda" in esf. I could also slice by
categories if I were to use that particular feature. You get
the idea. So, for starters, I'd like some name other than
simply ".xml" for the files.xml format... then I could enable it
everywhere.
Now as to the file format itself, it appears tailored to
blogging applications that statically render their content.
What are the created and modified dates for each of the dynamically
renderable slices I identified above? Should I calculate
number of bytes in each in anticipation that it might need to be
generated?
It is also not clear how one extends this format. If you
look at my archives page,
you can see that I have readily available a count of the number of
entries. Might this be useful?
Unfortunately, I can see how this dicussion will play out.
Somebody will say
that "files.xml is not a brilliant
format. It is a compromise. It is for blog browsers. That's all it
is for, for the 18,000th time." Then three months later
will say that it is the
perfect format for some other application that none of us have
thought of yet. And nobody will be clear as to what
applications are out there using this format, let alone know what
the impact will be of any change.
We've played this game before. Why not learn from the
past?
All I am saying is: give this format a name. And a
namespace. And specify from the beginning how (or even if) it
can be extended.