I saw The Incredibles this weekend and it was great. The animation was amazing, the story top notch and it had the right ratio of action to humor. This is probably one of the best super hero movies I've ever seen.

Rating: ***** out of *****

 

 

A recent post entitled Finally, a Use for Atom by Charles Miller got me thinking about the usefulness or lack thereof of the IETF Atom effort. It seems I wasn't the only one who started thinking this given a mail thread started by Tim Bray on the atom-syntax list entitled Posted PaceDeclareVictoryOnFormat where he writes

To: Atom WG <atom-syntax@xxxxxxx>
Subject: Posted PaceDeclareVictoryOnFormat
From: Tim Bray <Tim.Bray@xxxxxxx>
Date: Mon, 08 Nov 2004 14:13:17 -0800

See http://www.intertwingly.net/wiki/pie/PaceDeclareVictoryOnFormat

The world can use Atom, sooner rather than later. The return-on-investment of further WG time invested in polishing something that's already pretty good is starting to be very unattractive. Particularly when the Protocol draft seriously needs work and progress.

Note that this has not been formally placed at the front of the queue yet. -Tim

I posted some comments to the thread that reflect the same opinions from my post Mr. Safe's Guide to the RSS vs. ATOM debate, the relationship between the Atom syndication format and RSS is the same as that of XHTML and HTML; geeks will like it but there's no real concrete reason to use it over the old stuff that already works pretty well for the most part.

However I also reiterated that I think the Atom API is a worthwhile addition to the world of blogging technologies. I listed the problems with the current crop of blog posting APIs such as the Blogger API and MetaWeblog API in my post What's Wrong with the MetaWeblog API? from a year and a half ago

Security: The MetaWeblog API has no concept of security. Passwords are sent in plaintext as parameters to XML-RPC functions (i.e. they are sent in plain text on the wire as part of the XML message).

Strongly Coupled To XML-RPC: RSS and Joe Gregorio's CommentAPI have shown that one can build applications that retrieve and send XML documents from client to server directly using HTTP GET and POST instead of going through an added layer of indirection by using exlicit RPC mechanisms.
...
I also believe that there should be the API should not just be tied to XML-RPC but should have interfaces that utilize the XML Web Services family of technologies like SOAP and WSDL not just XML-RPC. There are many products and toolkits that support SOAP/WSDL/etc plus more are being built every day. It makes little sense to me that almost everywhere else in the software industry people are either exchanging XML documents using RESTian principles (i.e. HTTP GET and POST) or the XML Web Services family of technologies but when it comes to web content related technologies there is this anachronism where an arbitrarily different methodology is used.

Limited Functionality: The MetaWeblog API only allows one to either post and edit blog entries, fetch information about a specific user or change the website template. This is a drop in the bucket considering all the things one would like to do with a weblog engine which can be supported by the engine.

As time has passed some of my opinions on this matter have mellowed. Security is a big problem and one I don't think can be ignored. The fact that existing APIs depend on XML-RPC instead of more accepted industry practices such as using RESTian principles or SOAP+WSDL isn't that great but it isn't that big a deal. The issue of limited functionality is probably something that has to be lived with since for the API to be widely adopted it has to support a lowest common denominator of features. As long as the API can be extended then the fact that there isn't some functionality in the core isn't that bad.

So for me, the high order bit is security. I can see at least two ways to solve this problem listed in order of least disruptive to most disruptive

1. Blog editing tools and blog vendors moving towards using XML-RPC over HTTPS/SSL or at least use digest HTTP authentication instead of HTTP.
2. Blog editing tools and blog vendors moving towards using the Atom API over HTTPS/SSL or at least use digest HTTP authentication instead of HTTP.

A number of blog hosting services such as Blogger/Google and SixApart have moved towards doing (2) above. However it is unclear to me how much this has been embraced by builders of popular blog editing tools such as BlogJet and w::bloggar. Looking at the list of Atom Enabled client software I only see aggregators listed but not blog editing tools.

So I was curious, are there any major blog editing tools that support the Atom API? If not, do these tools support using the Blogger/MetaWeblog API over HTTPS/SSL? If not, is there any interest in doing the former or the latter any time soon?

 

There was a recent posting on the RSS Bandit bug forum entitled Weblog comments do not appear in listview where the author wrote

I use Wordpress to generate my site feed (http://www.chaoszone.org/index.xml). Wordpress supports wfw:commentRSS, but RSS Bandit is unable to show comments for posts in this feed inside the listview (the way it does for Dare's and other MSDN weblogs). Instead, I have to click through to go to the comments page.

I've since tweaked the basic Wordpress RSS2 generator routine to include slash:comments -- a temp feed is available here: http://www.chaoszone.org/rss-with-slashcomments.xml

Since the element in question is supported by RSS Bandit and I can view comments just fine in any dasBlog or Community Server::Blogs (formerly .TEXT) weblog I assumed this was a bug in WordPress. Eventually I tracked down the problem to an issue of capitalization.

The element in question is called wfw:commentRss in Chris Sells' original specification but incorrectly transcribed as wfw:commentRSS in Joe Gregorio's list of the wfw namespace elements. Since it looks like at least one blog tool uses the latter capitalization the next version of RSS Bandit will support both versions of the element. This means that comments to blog posts on WordPress-based blogs will now show up in the next version of RSS Bandit.

 

Many times when implementing XML specifications I've come across I've come up against feature that just seem infeasible or impractical to implement. However none of them have given me nightmares as they have my friend Mike Vernal, a program manager on the Indigo team at Microsoft. In his post could you stop the noise, i'm trying to get some rest ... he talks about spending nights tossing and turning having nightmares about how the SOAP mustUnderstand header attribute should be processed. In Mike's post More SOAP Sleepness he mentions having sleepless nights worrying about the behavior of SOAP intermediaries as described in Section 2.7: Relaying SOAP Messages.

This isn't to say I didn't have sleepless nights over implementing XML specifications when I worked on the XML team at Microsoft. One of the issues that consumed a lot more of my time than is reasonable is explained in Derek Denny-Brown's post Loving and Hating XML Namespaces 

Namespaces and your XML store
For example, load this document into your favorite XML store API (DOM/XmlBeans/etc)
 <book title='Loving and Hating XML Namespaces'>
   <author>Derek Denny-Brown</author>
 </book>
Then add the attribute named "xmlns" with value "http://book" to the <book> element. What should happen? Should that change the namespaces of the <book> and <author> elements? Then what happens if someone adds the element <ISBN> (with no namespace) under <book>? Should the new element automatically acquire the namespace "http://book", or should the fact that you added it with no namespace mean that it preserves it's association with the empty namespace?

In MSXML, we tried to completely disallow editing of namespace declarations, and mostly succeeded. There was one case, which I missed, and we have never been able to fix it because so many people found it an exploited it. The W3C's XML DOM spec basically says that element/attribute namespaces are assigned when the nodes are created, and never change, but is not clear about what happens when a namespace declaration is edited.

Then there is the problem of edits that introduce elements in a namespace that does not have an existing namespace declaration:
<a xmlns:p="http://p/">
  <b>
    ...
      <c p:x="foo"/>
    ...
  </b>
</a>
If you add attribute "p:z" in namespace "bar" to element <b>, what should happen to the p:x attribute on <c>? Should the implementations scan the entire content of <b> just in case there is a reference to prefix "p"?

Or what about conflicts? Add attribute "p:z" in namespace "bar" to the below sample... what should happen?
<a xmlns:p="http://p/" p:a="foo"/>

This problem really annoyed me while I was the PM for the System.Xml.XmlDocument class and the short-lived System.Xml.XPath.XPathDocument2. In the former, I found out that once you started adding, modifying and deleting namespace declarations the results would most likely be counter-intuitive and just plain wrong. Of course, the original W3C DOM spec existed before XML namespaces and trying to merge them in after the fact was probably a bad idea. With the latter class, it seemed the best we could do was try and prevent editing namespace nodes as much as possible. This is the track we decided to follow with the newly editable System.Xml.XPath.XPathNavigator class in the .NET Framework.

This isn't the most sleep depriving issue I had to deal with when trying to reflect the decisions in various XML specifications in .NET Framework APIs. Unsurprisingly, the spec that caused the most debate amongst our team when trying to figure out how to implement its features over an XML store was the W3C XML Schema Recommendation part 1: Structures. The specific area was the section on contributions to the Post Schema Validation Infoset and the specific infoset contribution which caused so much consternation was the validity property.

After schema validation an XML element or attribute should have additional metadata added to it related to validation such as it's type, its default value specified in the schema if any and whether it is valid or not according to its type. Although the validity property is trivial to implement on a read-only API such as the System.Xml.XmlReader class, it was unclear what would be the right way to expose this in other representations of XML data such as the System.Xml.XmlDocument class. The basic problem is "What happens to the validity propety of the element or attribute those of all its ancestors once the node is updated?". Once I change the value of an age element which is typed as an integer from 17 to seventeen what should happen. Should the DOM test every edit to make sure it is valid for that type then reject it otherwise? Should the edit be allowed but the validity property of the element and all its ancestors be changed? What if there is a name element with required first and last elements and the user wants to delete the first element and replace it with a different one? How would that be reflected with regards to the validity property of the name element?

None of the answers to the question we came up with satisfactory. In the end, we were stuck between a rock and a hard place so we made the compromise choice. I believe we debated this issue every other month for about a year.

 

According to the CTV article Election voter turnout highest in 30 years 

About 120 million people cast ballots, or just under 60 percent of eligible voters — the highest percentage turnout since 1968, said Curtis Gans, director of the nonpartisan Committee for the Study of the American Electorate.

In the 2000 election, when Republican George W. Bush squeaked out a win over Democrat Al Gore, slightly more than 54 per cent of eligible voters, or about 105.4 million, voted.

Gans said the modern record for voter turnout was 1960, when 65 per cent of those eligible cast ballots to back Democrat John Kennedy over Republican Richard Nixon.

More detailed figures were expected later Wednesday.

Still, despite the high turnout, 2004 did not prove to be a breakout year for young voters.

Exit polls indicated that fewer than one in 10 voters who came out on Tuesday were 18 to 24. That's about the same proportion of the electorate as in 2000.

It looks like P. Diddy's Vote Or Die campaign didn't get the MTV demographic out after all. However I was quite amused to see him as one of the election pundits on MSNBC last night.

 

Yesterday I found out that a shortage of styrofoam cups in the kitchen that we experienced in our building was actually occuring all over the Redmond campus. Some of us joked last night that this was the latest in the string of penny wise, pound foolish cost cuttings in the same vein as only having office supplies on one floor of the building.

This morning I realized that moving all of a particular resource to one floor to "cut costs" was actually an example used in The Dilbert Principle in a section entitled Companies That Turn On Themselves.

I wonder what other Dilbert-esque cost cutting moves folks out there have experienced? Post your favorites in the comments to this post.

 

I've been watching the hype about podcasting with some wariness but it looks like it is here to stay. I just noticed that Greg Reinacker (NewsGator) and Nick Bradbury (FeedDemon) have announced that they will have better support for RSS 2.0 enclosures and thus podcasting. This weekend I also started the roots of getting podcasting support into RSS Bandit, Torsten will likely finish this work once he is done with the GUI for NNTP newsgroup support.

Speaking of podcasting and RSS 2.0 enclosures, I agree 100% with Joshua Allen's points in his post, History of Podcasting. He wrote

Dave Winer doesn't want to end up like Eric Bina, written out of the history of a creation he helped usher into reality.  Adam steps up to make sure Dave gets credit.  This time, there is less reason to worry.  First, the WWW (which Eric helped enable) is now an independent and democratic public record which can triangulate the major media.  And blogs, which Dave helped enable, are one source of that public record.  The public record shows that Dave was planning “Radio” via RSS for a very long time.  Dave has talked about these ideas for a long time, but I have to admit that I wasn't quite prepared for how fast it would actually happen.  I believe credit goes to Adam for such a fast and effective bootstrap, but it also proves that all of the work on RSS laid a good foundation for quick incremental innovation.  

I also think that one of the major success factors was that the nattering nabobs ignored podcasting and dismissed it until it was too late to inject their stop energy.  Many of the nabobs were so convinced of their own stories about “RSS is broken”,  that it never occured to them that something like podcasting could be successful.  They were so busy trying to reinvent RSS that they ignored an idea that Dave has been giving away for free for years. 

There's a lot of innovation and interesting end user applications that can be built on RSS today. However many XML syndication geeks are prideful and would rather reinvent the wheel than use existing technology to solve real world problems.

 

Yesterday I found out my car had been broken into the previous night. I can't get over the fact that I had my car parked on the street at Pioneer Square until almost 2AM on Sunday but it gets broken into in the supposely secure underground parking garage of my apartment complex.

The wave of emotions washing over me this past 12 hours has been interesting. The ones that have stuck so far are the sense of violation and the anger. I've learned the hard way to never leave anything important in my car thinking that because its in the trunk it'll be "safe" .

Bah, I need to get ready for work.

 

 

Most people looking for a free RSS reader on Windows tend to gravitate towards SharpReader since it is the most popular one on Windows and the first they hear about. Recently I've begin to see more posts from people who've grown tired of its limited feature set and plain user interface that have switched to RSS Bandit.

In his post Vote With Your Download Dave writes

For the longest time I’ve used Sharpreader as my RSS reader. I had had some problems about which I contacted the SharpReader people. I think I sent two e-mails but never got a response. So I started looking.

I found RSS Bandit and I’m all about it now. I like the interface a little better and it’s got lots of nifty features that SharpReader doesn’t. (screenshots are here). So since both of these are free, and RSS Bandit is Open Source even, I can Vote with my download.

In his post RssBandit is awesome!  Imran Koradia writes

I've been using SharpReader for a while since that's the first one that turned up in google's search results on searching for an rss reader :) ! And considering I'm really lazy switching utility software even when it would seem the most logical thing to do, I've stayed on SharpReader for a while until yesterday. I finally switched to RssBandit. Not that SharpReader is bad, but RssBandit is more feature rich and looks way cooler than SharpReader :) I love the tabs that they've got since IE doesn't have them (which is the only reason why I switched to Netscape - I have no problems with IE as such otherwise..). Ofcourse, I could also use the local MSDN help to browse with multiple tabs but that somehow doesn't seem like a good idea to me..

We will be adding a lot more features and eye candy in the next release. There are one or two things SharpReader does that RSS Bandit doesn't such as the ability to delete posts which I'll be adding to RSS Bandit this weekend.  If you liked the last release then the next one will rock your world. I can't wait. ;) 

 

Almost two years ago I wrote a blog entry entitled Useful vs. Useless Abstractions which stated that the invention of URIs by the IETF/W3C crowd to replace the combination of URLs and URNs was a step backwards. I wrote

URIs are a merger of the syntax of URLs and URNs which seem to have been repurposed from their original task of identifying and locating network retrievable documents to being more readable versions UUIDs which can be used to identify any person, place or thing regardless of whether it is a file on the Internet or a feeling in your heart.

This addition to the URN/URL abstraction seemed to address some of the bits which may have been considered to be leaky (if I enter http://www.yahoo.com in my browser and it loads it from its cache then the URL isn't acting as a location but as an identifier). Others also saw URIs as a way for people who needed user friendly UUIDs for use on the Web. I've so far come into contact with URIs in two aspects of my professional experience and they have both left a bad taste in my mouth.

URIs and the Semantic Web: Ambiguity²

One problem with URIs is that they don't uniquely identify a single thing. Consider the following hyperlinked statements

Dare is a Georgia Tech alumni.

Dare's website is valid XHTML.

In the above statements I use the URI "http://www.25hoursaday.com" to identify both myself and my web page. This is a bad thing for the Semantic Web. If you read Aaron Swartz's excellent primer on the Semantic Web you will notice where he talks about RDF and its dependence on URIs
...
Now consider...

<http://aaronsw.com/> <http://love.example.org/terms/reallyLikes> <http://www.25hoursaday.com/> .

Can you tell whether Aaron really like my website or me personally from the above RDF statement? Neither can I. This inherrent ambiguity is yet another issue with the vision of the Semantic Web and the current crop of Semantic Web technologies that are overly dependent on URIs.

Over the past few years I've been on the W3C Technical Architecture Group mailing list I've seen this inherent ambiguity of URIs result in many lengthy, seemingly never-ending discussions about how to workaround this problem or whether it is even a problem in itself. The discussion thread entitled Information resources? which morphed into referendum on httpRange-14  is the latest incarnation of this permathread on the WWW-TAG mailing list.

I was much heartened to see that Tim Berners-Lee is beginning to see some of the problems caused by the inherent ambiguity of URIs. In his most recent response to the "referendum on httpRange-14 " thread he writes 

> It is a best practice that there be some degree of consistency
> in the representations provided via a given URI.

Absolutely.

> That applies *both* when a URI identifies a picture of
> a dog *and* when a URI identifies the dog itself.
>
> *All* URIs which offer consistent, predictable representations will be
> *equally* beneficial to users, no matter what they identify.

Now here seems to be the crunch.
The web architecture relies, we agree I think, on this consistency
or predictability of representations of a given URI.

The use of the URI in the web is precisely that it is associated
with that class of representations which could be returned for it.

Because the "class of representations which could be returned"
is a rather clumsy notion, we define a conceptual thing
which is related to any valid representation associated with the URI,
and as the essential property of the class is a similarity in
information content, we call the thing an Information Resource.

So a URI is a string whose sole use in the web architecture
is to denote that information resource.

Now if you say in the semantic web architecture that the same  will
identify a dog, you have a conflict.


>
>> The current web relies on people getting the same information from
>> reuse of the same URI.
>
> I agree. And there is a best practice to reinforce and promote this.
>
> And nothing pertaining to the practice that I and others employ, by
> using http: URIs to identify non-information resources, in any way
> conflicts with that.

Well, it does if the semantic web can talk about the web, as the
semantic web can't be ambiguous about what an identifier identifies in the way that
one can in english.

I want my agent to be able to access a web page, and then use the URI
to refer to the information resource without having to go and find some
RDF somewhere to tell it whether in fact it would be mistaken.

I want to be able to model lots and lots of uses of URIs in existing
technology in RDF. This means importing them wholesale,
it needs the ability to use a URI as a URI for the web page without
asking anyone else.

The saga continues. The ambiguity of URIs have also been a problem in XML namespaces since users of XML often wonder assume a namespace URI should lead to a network retrievable document when accessed.  Since they are URIs, this isn't necessarily true. If they were URLs it would be and if they were URNs they would not be.