Daniel Steinberg has a an article entitled Bosworth's Web of Data where he discusses some of the ideas Adam Bosworth evangelized in his keynote at the MySQL Users Conference 2005. Daniel writes,

Bosworth explained that the key factors that enabled the web began with simplicity. HTTP was simple enough that any "P" language or JavaScript programmer could build applications. On the consumption side, web browsers such as Internet Explorer 4 were committed to rendering whatever they got. This meant that people could be sloppy and they didn't need to be high priests of syntax. Because it was a sloppy standard, people who otherwise couldn't have authored content did. The fact that it was a standard allowed this single, simple, sloppy, open wire format to run on every platform.
...
The challenge is to take a database and do for the web what was done for content. Bosworth explained that you "need a model that allows for massively linear scalability and federation of information that can spread effortlessly across a federated web."

Solutions that were suggested were to use XML and XQuery. The problem with XML is that unlike HTML, there is not a single grammar. This removed the simple and sloppy aspects of the web. The problem with XQuery is the time it took to finish the specification. Bosworth noted that it took more than four years and that "anything that takes four years is not worth doing. It is over-designed. Intead, take six months and learn from customers."
...
The next solution used web services, which began as an easy idea: you send an XML request and you get XML back. Instead, the collection of WS-* specs were huge and again, overly complicated. Bosworth said that this was a deliberate effort on the part of the companies that control the specs, like IBM and Microsoft, which deliberately made the specification hard, because then only they could deliver technology to do it.
...
Bosworth predicts that RSS 2.0 and Atom will be the lingua franca that will be used to consume all data from everywhere. These are simple formats that are sloppily extensible. Anyone who wants to can use these formats to consume content or to author content. Contrast this with the Semantic Web, which requires that you get a large group of people to agree on the schema of everything.

There are lots of interesting ideas here. I won't dwell on the criticisms of XQuery & WS-* mainly because I tend to agree that they are both overdesigned and complicated. I also wont dwell on the apparent contradiction inherent in claiming that the Semantic Web is doomed because it requires people to agree on the same schema for everything then proposing that everyone agree on using RSS as the schema for all data on the Web. I have a suspicion of what he sees as the difference but I'll wait for a blog post from him clarifying that.

What I find very interesting is using RSS is the data access format for the Web. RSS gained popularity as a way to syndicate blog posts and news sites but its turned out to be a lot more versatile than that. Sites like Feedster and Amazon's OpenSearch technology show you can use RSS as a mechanism for providing search results and integrating search engines respectively. Podcasting shows you can use RSS to syndicate digital media content instead of just plain old text or HTML. With Amazon's syndicated feeds one can keep abreast of when new CDs, books and more are released.

Over the weekend I wrote the MSN Spaces photo album browser page which displays slideshows of all the photos in the various albums on a particular user's MSN Spaces space. This page also can display the photos on a randomly selected space. This webpage is entirely powered by RSS. The photos are obtained from the RSS feed for the Space and the list of random spaces is obtained by querying MSN search with the query "site:spaces.msn.com photo album" and requesting the results as RSS. In fact, the information from the MSN Spaces RSS feeds is enough to build something like the Flickr related tags browser, where instead of showing related tags one could show spaces related to the user from the information in their blog roll which happens to also be provided in the RSS feed. Pretty nifty and all without requiring building a REST, SOAP or XML-RPC API.

In situations where one simply wants to expose read-only data via a service on the Web, it's looking like RSS is the technology to beat. As more and more information is exposed as RSS feeds, there will be even more interesting things people will be able to do with this technology. At Microsoft we definitely are gung ho about exposing as much data as possible via RSS and I've been amazed at how much enthusiasm there is around the opportunites in this area.   

Side Note: Yesterday while at the Microsoft Research Social Computing Symposium I was chatting with Randy Farmer, who's one of the guys behind Yahoo! 360° and Yahoo's purchase of Flickr, and I mentioned that it seemed like 2003 was the year that RSS really started to take off. This was also the year that Dave Winer froze the RSS 2.0 spec and Sam Ruby gathered all the malcontents in the XML syndication space and gave them a shiny new toy to play with in Atom. Coincidence?

Almost four years ago I wrote an article entitled C# from a Java Developer's Perspective which is still one of the most popular comparisons of C# and Java on the Web. The article gets a couple thousand hits a month and I still get email about it from developers thanking me for writing it. Given the amount of changes in Java 1.5 5.0 and C# 2.0 I think the time has come to update this article. Below is my proposed table of contents for the new version. I'd appreciate comments on anything people thing is either missing or placed incorrectly.

1. The More Things Change The More They Stay The Same
   This section describes concepts and language features that are almost exactly the same in C# and Java.
1. We Are All Objects
2. Keyword Jumble
3. Of Virtual Machines and Language Runtimes
4. Heap Based Classes and Garbage Collection
5. Arrays Can Be Jagged
6. No Global Methods
7. Interfaces, Yes. Multiple Inheritance, No.
8. Strings Are Immutable
9. Unextendable Classes
10. Throwing and Catching Exceptions
11. Member Initialization at Definition and Static Constructors
12. Generics - new!!!
13. Boxing - new!!!
14. Variable Length Parameter Lists - new!!!
    
    
2. The Same But Different
   This section describes concepts and language features that differ either only in syntax or in some similarly minor manner between C# and Java.
   1. Main Method
   2. Inheritance Syntax
   3. Run Time Type Identification (is operator)
   4. Namespaces
   5. Constructors, Destructors and Finalizers
   6. Synchronizing Methods and Code Blocks
   7. Access Modifiers
   8. Reflection
   9. Declaring Constants
   10. Primitive Types
   11. Array Declarations
   12. Calling Base Class Constructors and Constructor Chaining
   13. For or is that foreach loops? - new!!!
   14. Metadata Annotations - new!!!
   15. Enumerations - new!!!
       
       
3. An Ever So Slight Feeling of Dj Vu
   This section describes concepts and language features that exist in C# that are similar to those that exist in Java but with a significant difference.
   1. Nested classes
   2. Threads and Volatile Members
   3. Operator Overloading
   4. switch Statement
   5. Assemblies
   6. Collections
   7. goto (no longer considered harmful)
   8. Virtual Methods (and final ones too)
   9. File I/O
   10. Object Serialization
   11. Documentation Generation from Source Code Comments
   12. Multiple Classes in a Single File
   13. Importing Libraries
   14. Events
   15. Cross Language Interoperability
       
       
4. Now For Something Completely Different
   This section describes language features and concepts that exist in C# and have no Java counterpart.
1. Deterministic Object Cleanup
2. Delegates - changed!!!
3. Value Types (Structs)
4. Run Time Type Identification (as operator)
5. Properties - changed!!!
6. Multidimensional Arrays
7. Indexers
8. Preprocessor Directives - changed!!!
9. Aliases
10. Runtime Code Generation
11. Pointers and Unsafe Code
12. Pass by Reference
13. Verbatim Strings
14. Overflow Detection
15. Explicit Interface Implementation
16. Friend Assemblies - new!!!
17. The Global Namespace Qualifier - new!!!
18. Continuations (Iterators) - new!!!
19. Partial Classes - new!!!
20. Anonymous Methods - new!!!
    
    
5. Wish You Were Here
   This section describes language features and concepts that exist in Java and have no C# counterpart.
   1. Checked Exceptions
   2. Cross Platform Portability (Write Once, Run Anywhere)
   3. Extensions
   4. strictfp
   5. Dynamic Class Loading
   6. Interfaces That Contain Fields
   7. Anonymous Inner Classes
   8. Static Imports - new!!!
      

Aaron Skopnnard has posted a response to my Contract-First XML Web Service Design is No Panacea blog post. In his post The virtue of contract-first Aaron Skonnard writes

I love being challenged on my opinions. I've been challenged extensively regarding my opinion on contract-first development, although mostly by folks at Microsoft like Don , Doug , and Dare . The funny thing is when I have the same discussions with folks in the field building systems today, it's a no-brainer.

 

So why the disconnect between vendors and the rest of the world?

 

I believe it's because most vendors don't see (or appreciate) the main virtue of the contract-first approach, which has more to do with collaboration than interoperability. The latter is a result of the former. Let me explain.

 

Interoperability is the net result of a well-designed contract. By "well-designed" I mean a contract that experiences fewer interoperability issues when used across a variety of toolkits. Simply using contract-first does not guarantee a good contract. However, increased collaboration during contract does. This means getting all parties (everyone who will have to deal with the contract) involved early, during design, so you can identify what will and won't work in each implementation environment. This allows you to bring local expertise to the table early in the process before the implementation investment begins. This process influences the subset of XSD constructs that can be safely used given the identified limitations.

I mentioned in a recent post that I was considering writing an article entitled Using Javascript, XMLHttpRequest and RSS to create an MSN Spaces photo album browser. It actually took less work than I thought to build a webpage that allows you to browse the photo albums in a particular person's Space or from a randomly chosen Space. 

I haven't used Javascript in about 5 years but it didn't take much to put the page together thanks mostly to the wealth of information available on the Web.

You can find the page at http://www.25hoursaday.com/spaces/photobrowser.html 

The page requires Javascript and currently only works in Internet Explorer but I'm sure that some intrepid soul could make it work in Firefox in a couple of minutes. If you can, please send me whatever changes are necessary.  

The current issue of Seattle's favorite free weekly newspaper has an article entitled Microsoft Caves on Gay Rights which describes recent happenings in local politics about how Microsoft apparent withdrawal of support for a state bill that would prevent discrimination against gays and lesbians may have been key in preventing the law from passing.

I've tried to write down my feelings about the issue several times over the past few days but words have escaped me. In the meantime you should read some posts from others at Microsoft who've done a better job a capturing their disappointment with our employer than I seem able.

1. Robert Scoble: Steve Ballmer's memo posted, my reply
2. Cyrus Najmabadi: Gay Rights (part 2)
3. Adam Barr: Microsoft and the Anti-Discrimination Bill

I also strongly disagree with Vic Gundotra's post in his response Responding to Scoble. Corporations should not be amoral entities that only exist to generate money. They employee members of a community, they exist as part of community and their actions affect both local and global communities. Sometimes the greatest sins are acts of omission instead of commission.

I hope this feeling of disappointment will soon pass.

Every once in a while I see articles like Aaron Skonnard's Contract-First Service Development which make me shake my head in sorrow. His intentions are good but quite often advising people to design their XML Web services starting from an XSD/WSDL file instead of a more restricted model leads to more problems than what some have labelled the "code-first" approach.

For example, take this recent post to the XML-DEV mailing list entitled incompatible uses of XML Schema

I just got a call from a bespoke client (the XML guru in a large bank)
asking whether I knew of any XML Schema refactoring tools.

His problem is that one of their systems (from a big company)
does not handle recursive elements.  Another one of their
systems (from another big company) does not handle substitution
groups (or, at least, dynamic use of xsi:type.) Another of their
systems (from a third big company) does not handle wildcards.
(Some departments also used another tool that generated ambiguous
schemas.)

This is causing them a major headache: they are having to
refactor 7,000 element schemas by hand to munge them into
forms suited for each system.

Their schema-centricism has basically stuffed up the ready
interoperability they thought they were buying into with XML,
on a practical level. This is obviously a trap: moving to a
services-oriented architecture means that the providers can
say "we provide XML with a schema" and the pointy-headed bosses
can say "you service-user: this tool accepts XML with a schema
so you must use that!" and the service-user has little recourse.

This is one of the problems of contract first development that many of the consultants, vendors and pundits who are extolling its virtues fail to mention. A core fact of building XML Web services that use WSDL/XSD as the contract is that most people will use object<->XML mapping technologies to either create or consume the web services. However there are fundamental impedance mismatches between the W3C XML Schema Definition (XSD) Language and objects in a traditional object oriented programming language that ensure that these mappings will be problematic. I have written about these impedance mismatches several times over the past few years including posts such as The Impedence Mismatch between W3C XML Schema and the CLR.

Every XML Web Service toolkit that consumes WSDL/XSD and generates objects has different parts of the XSD spec that they either fail to handle or handle inadequately. Many of the folks encouraging contract first development are refusing to acknowledge that if developers  build schemas by hand for use in XML Web Services, it is likely they will end up using capabilities of XSD that are not supported by one or more of their consuming applications. The post from XML-DEV is just one example of this happening. When I was the program manager for XML Schema technologies in the .NET Framework I regularly had to help customers who had to deal with the interoperability problems they encountered because they'd read some article extolling the virtues of schema first design which failed to acknowledge the realities of the XML Web Service landscape.

From my experience "contract first" design is actually more likely to lead to interoperability problems than "code first" design. The only time this isn't the case is when the schema designer actually pays attention to use a minimal subset of XSD as opposed to using its full capabilities. This is one of the reasons I have tried to provide some guidance on what XSD features to avoid in my XML Schema Design guidelines series on XML.com.

However it is far easier to avoid these missteps if one starts from objects instead of XSD/WSDL since the expressiveness of objects is less than that of XSD which automatically means the web service contracts are less complicated. I remember getting this insight from Don Box and Doug Purdy a couple of months ago and rejecting it at the time since it seemed anti-XML but now I realize that it is actually the most practical thing to do.

Walt Mossberg of the Wall Street Journal recently tried out MSN Spaces and has a review in today's issue. His review Microsoft Service Lets You Create A Nice Blog, But Limits Tweaking contains the following excerpts

If you think that only techies can launch a blog, or Web log, to share their views with friends, family or the whole Internet -- think again. Numerous online services make it dead simple for anyone to create a blog, at no cost, with no technical knowledge whatsoever.
...
Google got a big jump when it bought a service called Blogger (blogger.com). Today, the company hosts an estimated eight million blogs. Yahoo is developing an elaborate service called Yahoo 360 (360.yahoo.com), which offers blogging and other features designed to connect people. It's currently in a test phase, open only by invitation.

Microsoft has just launched its own blogging service, called MSN Spaces (spaces.msn.com). Because it's the newest of the giants' offerings to complete its test phase, I decided to try it out. Microsoft says it already has more than seven million blogs in Spaces, and is adding new ones at a rate of over 100,000 a day.

My verdict: MSN Spaces is very well done. It makes it easy to create a simple, attractive blog with text, links and photos, and to customize the blog in interesting ways

The review was quite favorable which is great news for us because it means we've done a good job at hitting our target demographic. This is awesome given that this is just the first version. 

A number of the criticisms in the article related to limited customizability are things we are aware about and plan to address in future releases. Y'all should nag Karen with your ideas. :)

As for the number of spaces created so far, that isn't a typo. We've added over 2.5 million spaces since it came out of beta two weeks ago. 100,000 new spaces a day is actually a conservative number, we were seeing multiples of that number shortly after launch but I assume our current adoption rate will hover at that number for now.

I recently stumbled on a post entitled The end of the quest for the perfect RSS reader which made my day. The author wrote

RSS readers have lately been appearing all over the place, however, until recently I wasn’t able to find the perfect one. My needs are not huge. I want a reader which can synchronize feeds and read posts between several PCs, have a useful and selectable notification mechanism so I don’t miss important news, but still don’t get bothered with less important ones, display feeds in a tree without favicons, be robust and fairly fast, provide descent search functionality and saved searches, flag news items for easy follow up and review.

I have tried most of the existing Windows and web based aggregators, and each one had some of these missing. I recently checked the new version of RSS Bandit and my quest for the perfect RSS reader seems to have come to an end. RSS Bandit features all I need and provides even more nice goodies like integrated Feedster and Google searches.

If you are not completely satisfied with your reader, give RSS Bandit a spin. You won’t regret it.

It's really good to see people getting so much use of my favorite RSS reader. Of course, there is still a lot of interesting stuff we'd like to add to make it even better. Check out the roadmap for the Nightcrawler release to see where we plan to go in the next release.

If you currently aren't an RSS Bandit user but would like to try it out, download the latest version from here.

Exhibit A: From The Submarine by Paul Graham

PR people fear bloggers for the same reason readers like them. And that means there may be a struggle ahead. As this new kind of writing draws readers away from traditional media, we should be prepared for whatever PR mutates into to compensate. When I think how hard PR firms work to score press hits in the traditional media, I can't imagine they'll work any less hard to feed stories to bloggers, if they can figure out how.

Exhibit B: From My Dinner With Microsoft's Jim Allchin in Thomas Hawk's weblog

Last night I had a unique opportunity to sit down with Jim Allchin, Microsoft’s Group Vice President for Platforms, for dinner along with a group of other bloggers and technologists and discuss the future development of Longhorn as well as see an early demo of the Longhorn technology firsthand.

Exhibit C: From A comment on Slashdot by Thomas Hawk about the dinner

I do feel that there is room in the world of journalism for hard news, op/ed and yes, openly biased writing where the blogger places him or her self as a participant in the news itself.

Was I thrilled to be having dinner with Allchin? Of course. I'm a huge Microsoft enthusiast. I have been an advocate of the digital home for many years and I think that Microsoft may represent our best chance possible of making the digital home of the future a reality.

Was I really enthused about Longhorn? Absolutely. From what I saw it was really was amazing. I spend hundreds of hours every year organizing digital media in front of all five of my Windows PCs. The technology that I saw will save me hundreds of hours of work going forward. This is really exciting to me at a personal level.

It looks like I didn't get an Extreme XML column out last month. Work's been hectic but I think I should be able to start on a column by the end of the week and get it done before the end of the month. I have a couple of ideas I'd like to write about but as usual I'm curious as to what folks would be interested in reading about. Below are three article ideas in order of preference. 

1. Using Javascript, XMLHttpRequest and RSS to create an MSN Spaces photo album browser: The RSS feed for a space on MSN Spaces contains information about the most recent updates to a user's blog, photo album and lists. RSS items containing lists are indicated by using the msn:type element with the value "photoalbum". It is possible to build a photo album browser for various spaces by using a combination of Javascript for dynamic display and XMLHttpRequest for consuming the RSS feed. Of course, my code sample will be nowhere near as cool as the Flickr related tag browser.

2. Fun with operator overloading and XML: This would be a follow up piece to my Overview of Cω article. This article explores how one could simulate adding XML specific language extensions by overloading various operators on the System.Xml.XmlNode class.

3. Processing XML in the Real World: 10 Things To Worry About When Processing RSS feeds on the Web: This will be an attempt to distill the various things I've learned over the 2 years I've been working on RSS Bandit. It will cover things like how to properly use the System.Xml.XmlReader class for processing RSS feeds in a streaming fashion, bandwidth saving tips from GZip encoding to sending If-Modified-Since/If-None-Match headers in the request, dealing with proxy servers and authentication.

Which ones would you like to see and/or what is your order of preference?