Microsoft is adding something to IE 8 called “webslices”. A webslice is a part of a webpage that updates and can be subscribed to – for example, a weather forecast.

A webslice is different that a syndication feed because:

1. it’s part of a webpage, rather than an independent feed (though it can have an independent feed also)
2. it’s a single thing that updates, as opposed to a pipe that new things (such as blog posts) are coming down one after the other

You can read the webslices spec on this page and brief commentary here.

Now, what makes this interesting to me is that it’s based on the hAtom microformat (which I authored and championed). It’s based but unfortunately it’s not the hAtom microformat, as they add their own top level concept, the “hslice”.

Now, I can understand to some degree why Microsoft did this:

• a webslice is the concept of a feed with a single item that’s continually being updated
• hAtom requires an “author” element
• hAtom requires an “updated” or “created” element
• people think that hAtom is about weblogs – but it’s not true.

These issues are addressable. hAtom 0.2 is going to drop the requirement for the “author” element – it will be assumed to be some value (what, we’re not sure yet) if it’s not physically present. hAtom isn’t about weblogs – it’s about semantically marking up microcontent – and so is entirely applicable to webslices.

The “updated/created” issue is a little tougher. Allow me to suggest that if not present, these default to now, and leave it up to parsers to figure out if things have changed. This will together with the time-to-live (ttl) element MS is proposing in the spec.

I humbly suggest then that MS change the webslice spec so that instead of looking like this:

<div class="hslice" id="1">
 <p class="entry-title">Item - $66.00</p>
 <div class="entry-content">high bidder: buyer1
 …
</div>
</div>

they make it look like this

<div class="hfeed hentry" id="1">
 <p class="entry-title">Item - $66.00</p>
 <div class="entry-content">high bidder: buyer1
 …
</div>
</div>

That is, change “hslice” to “hfeed hentry”. The beauty of this is that there’ll be no reason now why all the tools MS develops for working with webslices will also work with any page that contains hAtom.

If they’re interest in only seeing items that narrowly conform to the webslices spec (i.e. single item feeds), they can just look for single item feeds with no created/updated/author fields. But I think they should go all out and recognize all hAtom items and incidentally help put together the semantic web.

Read about it over on the Onamap blog.

Techcrunch reports:

In an encouraging act of collaboration, Google, Yahoo and Microsoft announced tonight that they will all begin using the same Sitemaps protocol to index sites around the web. Now based at Sitemaps.org, the system instructs web masters on how to install an XML file on their servers that all three engines can use to track updates to pages. This should make it easier to get your pages indexed in a simple and standardized way. People who use Google Sitemaps don’t need to change anything, those maps will now be indexed by Yahoo and Microsoft.

I.e. it looks like they all agreed on Google's defacto standard?

"Small Business" IT World predicts:

I estimate each Vista user will cost your company between $3,250 and $5,000. That's each and every Vista user. Money will go to Microsoft for Vista and Office 2007, to hardware vendors for new PCs and components, and possibly a few bucks to Apple for those users jumping to a Mac. After all, if Apple's higher cost has been the factor keeping your company from trying a Mac, that factor just washed away.

That's a lot of money for small or big businesses. And what makes Office 2007 or Vista better than what you have now. Ummm ... more rounded corners? Or just the fact that MS will someday cut off tech support. Hell, I was happy with Windows/Office 2000.

IronPython 1.0 is available:

IronPython is a new implementation of the Python programming language running on .NET. It supports an interactive console with fully dynamic compilation. It is well integrated with the rest of the .NET Framework and makes all .NET libraries easily available to Python programmers, while maintaining full compatibility with the Python language.

Jim Hugunin explains the story IronPython here:

I started work on IronPython almost 3 years ago.  My initial motivation for the project was to understand all of the reports that I read on the web claiming that the Common Language Runtime (CLR) was a terrible platform for Python and other dynamic languages.  I was surprised to read these reports because I knew that the JVM was an acceptable platform for these languages.  About 9 years ago I’d built an implementation of Python that ran on the JVM originally called JPython and later shortened to Jython.  This implementation ran a little slower than the native C-based implementation of Python (CPython), but it was easily fast enough and stable enough for production use – testified to by the large number of Java projects that incorporate Jython today.

I wanted to understand how Microsoft could have screwed up so badly that the CLR was a worse platform for dynamic languages than the JVM.  My plan was to take a couple of weeks to build a prototype implementation of Python on the CLR and then to use that work to write a short pithy article called, "Why the CLR is a terrible platform for dynamic languages".  My plans quickly changed as I worked on the prototype, because I found that Python could run extremely well on the CLR – in many cases noticeably faster than the C-based implementation.  For the standard pystone benchmark, IronPython on the CLR was about 1.7x faster than the C-based implementation.

The more time I spent working on IronPython and with the CLR, the more excited I became about its potential to finally deliver on the vision of a single common platform for a broad range of languages.  At that same time, I was invited to come out to Microsoft to present IronPython and to talk with members of the CLR team about technical issues that I was running into.  I had a great time that day working through these issues with a group of really smart people who all had a deep understanding of virtual machines and language implementation.  After much reflection, I decided to join the CLR team at Microsoft where I could work with the platform to make it an even better target for dynamic languages and be able to have interesting technical discussions like that every day.

(Plain-old) Python already works quite well with the Microsoft Platform. However, I expect the best work Microsoft is doing these days revolves around .NET, so then next time I look to do Windows work in Python, I'm definitely going to have a look at IronPython.