You know you're a geek when it's not even 7AM but you've already spent half the morning reading a whitepaper about Microsoft's plans to integrate XML and relational query language functionality into the .NET Framework with Linq.  C# 3.0 is going to be hot.

Like it's forefather X# Xen Cω, XLinq does an amazing job of integrating XML directly into the Common Language Runtime and the C#/VB.NET programming languages. Below are some code samples to whet your appetite until I can get around to writing an article later this year

  1. Creating an XML document

    XDocument contactsDoc = 
    new XDocument(
    new XDeclaration("1.0", "UTF-8", "yes"),
    new XComment("XLinq Contacts XML Example"),
    new XProcessingInstruction("MyApp", "123-44-4444"),
    new XElement("contacts",
    new XElement("contact",
    new XElement("name","Patrick Hines"),                                       
    new XElement("phone", "206-555-0144"),
    new XElement("address",
    new XElement("street1", "123 Main St"),
    new XElement("city", "Mercer Island"),
    new XElement("state", "WA"),
    new XElement("postal", "68042")

  2. Creating an XML element in the "" namespace

    XElement contacts = new XElement("{}contacts");

  3. Loading an XML element from a file

    XElement contactsFromFile = XElement.Load(@"c:\myContactList.xml");

  4. Writing out an array of Person objects as an XML file

    class Person {
            public string Name;
            public string[] PhoneNumbers;

    var persons = new [] { new Person
    "Patrick Hines"
                                   PhoneNumbers =
    new string
    "206-555-0144", "425-555-0145"
    new Person {Name="Gretchen Rivas"
                                       PhoneNumbers =
    new string

    XElement contacts = new XElement("contacts",
    from p in persons
    select new XElement("contact"
    new XElement("name"
    , p.Name),
    from ph in
    select new XElement("phone"
    , ph)



  5. Print out all the element nodes that are children of the <contact> element

    foreach (x in contact.Elements()) {

  6. Print all the <phone> elements that are children of the <contact> element

    foreach (x in contact.Elements("phone")) {

  7. Adding a <phone> element as a child of the <contact> element

    XElement mobilePhone = new XElement("phone", "206-555-0168");

  8. Adding a <phone> element as a sibling of another <phone> element

    XElement mobilePhone = new XElement("phone", "206-555-0168");
    XElement firstPhone = contact.Element("phone"

  9. Adding an <address> element as a child of the <contact> element

    contact.Add(new XElement("address",
    new XElement("street", "123 Main St"
    new XElement("city", "Mercer Island"
    new XElement("state", "WA"
    new XElement("country", "USA"
    new XElement("postalCode", "68042"

  10. Deleting all <phone> elements under a <contact> element


  11. Delete all children of the <address> element which is a child of the <contact> element


  12. Replacing the content of the <phone> element under a <contact> element


  13. Alternate technique for replacing the content of the <phone> element under a <contact> element

    contact.SetElement("phone", "425-555-0155");

  14. Creating a contact element with attributes multiple phone number types

    XElement contact =
    new XElement("contact"
    new XElement("name", "Patrick Hines"
    new XElement("phone"
    new XAttribute("type", "home")
    new XElement("phone"
    new XAttribute("type", "work")

  15. Printing the value of the <phone> element whose type attribute has the value "home"

    foreach (p in contact.Elements("phone")) {
    if ((string)p.Attribute("type") == "home"
    Console.Write("Home phone is: " + (string

  16. Deleting the type attribute of the first <phone> element under the <contact> element


  17. Transforming our original <contacts> element to a new <contacts> element containing a list of <contact> elements whose children are <name> and <phoneNumbers>

    new XElement("contacts",
    from c in contacts.Elements("contact"
    select new XElement("contact"
    new XElement("phoneNumbers", c.Elements("phone"

  18. Retrieving the names of all the contacts from Washington, sorted alphabetically 

    from    c in contacts.Elements("contact")
    where   (
    string) c.Element("address").Element("state") ==
    orderby (string) c.Element("name"
    select  (
    string) c.Element("name");

All examples were taken from the XLinq: .NET Language Integrated Query for XML Data  white paper.


Categories: XML

A lot of the comments in the initial post on the Microsoft Gadgets blog are complaints that the Microsoft is copying ideas from Apple's dashboard. First of all, people should give credit where it is due and acknowledge that Konfabulator is the real pioneer when it comes to desktop widgets. More importantly, the core ideas in Microsoft Gadgets were pioneered by Microsoft not Apple or Konfabulator.

From the post A Brief History of Windows Sidebar by Sean Alexander

Microsoft "Sideshow*" Research Project (2000-2001)

While work started prior, in September 2001, a team of Microsoft researchers published a paper entitled, "Sideshow: Providing peripheral awareness of important information" including findings of their project. 
The research paper provides screenshots that bear a striking resemblance to the Windows Sidebar.  The paper is a good read for anyone thinking about Gadget development.  For folks who have visited Microsoft campuses, you may recall the posters in elevator hallways and Sidebar running on many employees desktops.  Technically one of the first teams to implement this concept

*Internal code-name, not directly related to the official, “Windows SideShow™” auxiliary display feature in Windows Vista.

Microsoft “Longhorn” Alpha Release (2003)

In 2003, Microsoft unveiled a new feature called, "Sidebar" at the Microsoft Professional Developer’s Conference.  This feature took the best concepts from Microsoft Research and applied them to a new platform code-named, "Avalon", now formally known as Windows Presentation Foundation...

 Microsoft Windows Vista PDC Release (2005)

While removed from public eye during the Longhorn plan change in 2004, a small team was formed to continue to incubate Windows Sidebar as a concept, dating back to its roots in 2000/2001 as a research exercise. Now Windows Sidebar will be a feature of Windows Vista.  Feedback from customers and hardware industry dynamics are being taken into account, particularly adding support for DHTML-based Gadgets to support a broader range of developer and designer, enhanced security infrastructure, and better support for Widescreen (16:10, 16:9) displays.  Additionally a new feature in Windows Sidebar is support for hosting of Web Gadgets which can be hosted on sites such as or run locally.  Gadgets that run on the Windows desktop will also be available for Windows XP customers – more details to be shared here in the future.

So the desktop version of "Microsoft Gadgets" is the shipping version of Microsoft Research's "Sideshow" project. Since the research paper was published a number of parties have shipped products inspired by that research including MSN Dashboard, Google Desktop and Desktop Sidebar but this doesn't change the fact that the Microsoft is the pioneer in this space.

From the post Gadgets and by Sanaz Ahari was initially released on February 2005, on – since then we’ve been innovating regularly (,, and working towards accomplishing our goals:

  • To bring the web’s content to users through:
    • Rich DHTML components (Gadgets)
    • RSS and behaviors associated with RSS
    • High customizability and personalization
  • To enable developers to extend their start experience by building their own Gadgets

Yesterday marked a humble yet significant milestone for us – we opened our "Atlas" framework enabling developers to extend their experience. You can read more it here: The key differentiators about our Gadgets are:

  • Most web applications were designed as closed systems rather than as a web platform. For example, most customizable "aggregator" web-sites consume feeds and provide a fair amount of layout customization. However, the systems were not extensible by developers. With, the experience is now an integrated and extensible application platform.
  • We will be enriching the gadgets experience even further, enabling these gadgets to seamlessly work on Windows Sidebar

The stuff is really cool. Currently with traditional portal sites like MyMSN or MyYahoo, I can customize my data sources by subscribing to RSS feeds but not how they look. Instead all my RSS feeds always look like a list of headlines. These portal sites usually use different widgets for display richer data like stock quotes or weather reports but there is no way for me to subscribe to a stock quote or weather report feed and have it look the same as the one provided by the site. fundamentally changes this model by turning it on its head. I can create a custom RSS feed and specify how it should render in using JavaScript which basically makes it a gadget, no different from the default ones provided by the site.

From my perspective, we're shipping really innovative stuff but because of branding that has attempted to cash in on the "widgets" hype, we end up looking like followers and copycats.

Marketing sucks.


Categories: MSN

September 13, 2005
@ 11:32 PM has always been an innovative service but today's announcements have kicked it up a notch. In his post A Preview of Web 3.0, Scott Isaacs writes

Today's preview of the Developer illustrates fundamental shifts in web programming patterns:

  • DHTML-based Gadgets consumes DHTML-based components called Gadgets. These Gadgets can be created by any developer, hosted on any site, and consumed into the experience. The model is completely distributed. You can develop components derived from other components on the web.
  • Adding Behavior to RSS
    RSS (Really Simple Syndication) is an incredible platform for sharing content and information. Today all RSS feeds are treated equally by aggregators. integrates the world of RSS with Gadgets enabling any feed to optionally be associated with a rich, interactive experience. Some feeds present information that may be better presented in an alternative format. Other feeds leverage extensions or provide extra semantics beyond standard RSS (e.g., Open Search, Geo-based coordinates, etc). By enabling a feed to define a unique experience or consume an existing one, the richness of the aggregator experience can improve organically without requiring a new application. Of course, we also allow the user to control whether a custom experience is displayed for a feed.
  • Open-ended Application Model is what I call an open-ended application. An open-ended application consumes Gadgets and provides core application services and experiences. This is and has been the model since its inception (how do you think they released new features every week?). By opening up, we have removed the boundaries around features and experiences. The community of developers and publishers can now define and control the richness of the experience.

These are the web-applications of the future - applications that can integrate not only content (e.g., RSS) but associated behaviors and services. Today, via, the developer community can preview MSN's client technology and infrastructure. At, you will find early samples and documentation. This site will be continually improved with more documentation and samples. Go and build Gadgets and custom experiences for your feeds. Most importantly, since we are far from finished, please give us feedback. The platform can only improve with your feedback. Also, we are always looking for interesting Gadgets and custom RSS experiences.

I'm not sure I'm feelin' the "Web 3.0" monicker but the extensibility of the site is definitely cool beans. I remember a conversation I had with Steve Rider I had during the early days of the site where I asked if it would be possible to customize how different RSS feeds were displayed. At the time, I had noticed that there were three primary widget types for weather reports, stock quotes and headlines. I suggested that it would be cool if people could add annotations to the RSS feed to tell it how to display on the Being an XML geek I was was thinking of extensions such as a start:display-style element which could have values like "columns", "headlines" or "rows".

Steve thought my idea was cool and chatted with Scott Isaacs about it. Since Scott is the DHTML guru of DHTML gurus, he kicked the idea up a notch and actually designed an infrastructure where sophisticated rendering behavior could be associated with an RSS feed using JavaScript. The rest is history.

Damn, I love working here.


Categories: MSN | Web Development

September 13, 2005
@ 11:02 PM

The former co-workers (the Microsoft XML team) have been hard at work with the C# language team to bring the XML query integration into the core languages for the .NET Framework. From Dave Remy's post Anders unveils LINQ! (and XLinq) we learn

In Jim Allchin's keynote At PDC2005 today Anders Hejlsberg showed the LINQ project for the first time.  LINQ stands for Language Integrated Query.  The big idea behind LINQ is to provide a consistent query experience across different "LINQ enabled" data access technologies AND to allow querying these different data access technologies in a single query.  Out of the box there are three LINQ enabled data access technologies that are being shown at PDC.  The first is any in-memory .NET collection that you foreach over (any .NET collection that implements IEnumerable<T>).  The second is DLinq which provides LINQ over a strongly typed relational database layer.  The third, which I have been working on for the last 6 months or so (along with Anders and others on the WebData XML team), is XLinq, a new in-memory XML programming API that is Language Integerated Query enabled.  It is great to get the chance to get this technology to the next stage of development and get all of you involved.  The LINQ Preview bits (incuding XLinq and DLinq) are being made available to PDC attendees.  More information on the LINQ project (including  the preview bits) are also available online at

This is pretty innovative stuff and I definitely can't wait to download the bits when I get some free time. Perhaps I need to write an article exploring LINQ for the way I did with my Introducing C-Omega article? Then again, I still haven't updated my C# vs. Java comparison to account for C# 2.0 and Java 1.5. It looks like I'll be writing a bunch of programming language articles this fall. 

Which article would you rather see?


Categories: XML

While perusing my referrer logs I noticed that I was receiving a large number of requests from Google Desktop. In fact, I was serving up more pages to Google Desktop users than to RSS Bandit users. Considering that my RSS feed is included by default in RSS Bandit and there have been about 200,000 downloads of RSS Bandit this year it seemed extremely unlikely that there are more people reading my feed from Google Desktop than RSS Bandit.

After grepping my referrer logs, I noticed an interesting pattern when it came to accesses from the Google Desktop RSS reader. Try and see if you notice it from this snapshot of a ten minute window of time.

2005-09-13 16:31:05 GET /weblog/SyndicationService.asmx/GetRss - 80.58.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:32:13 GET /weblog/SyndicationService.asmx/GetRss - 65.57.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:32:36 GET /weblog/SyndicationService.asmx/GetRss - 209.221.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:33:05 GET /weblog/SyndicationService.asmx/GetRss - 64.116.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:33:12 GET /weblog/SyndicationService.asmx/GetRss - 209.204.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:33:20 GET /weblog/SyndicationService.asmx/GetRss - 68.188.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:34:48 GET /weblog/SyndicationService.asmx/GetRss - 209.221.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:35:25 GET /weblog/SyndicationService.asmx/GetRss - 64.116.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:35:32 GET /weblog/SyndicationService.asmx/GetRss - 209.204.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:35:40 GET /weblog/SyndicationService.asmx/GetRss - 68.188.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:36:14 GET /weblog/SyndicationService.asmx/GetRss - 80.58.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:37:33 GET /weblog/SyndicationService.asmx/GetRss - 65.57.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:37:46 GET /weblog/SyndicationService.asmx/GetRss - 209.204.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:37:55 GET /weblog/SyndicationService.asmx/GetRss - 68.188.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:37:55 GET /weblog/SyndicationService.asmx/GetRss - 64.116.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:39:19 GET /weblog/SyndicationService.asmx/GetRss - 196.36.*.1* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:39:31 GET /weblog/SyndicationService.asmx/GetRss - 12.103.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:39:55 GET /weblog/SyndicationService.asmx/GetRss - 18.241.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:40:11 GET /weblog/SyndicationService.asmx/GetRss - 63.211.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:40:15 GET /weblog/SyndicationService.asmx/GetRss - 64.116.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200
2005-09-13 16:41:23 GET /weblog/SyndicationService.asmx/GetRss - 80.58.*.* Mozilla/4.0+(compatible;+Google+Desktop) - 200

The *'s are there to protect the privacy of the people accessing my RSS feed. However it is clear that not only is Google Desktop fetching my RSS feed every 5 minutes it is also not using HTTP Conditional GET requests. WTF?

Since I couldn't find a place to send feedback about this product, I've posted it to my blog. I hope Google fixes this soon, I'd hate to have to ban their client because it is wasting my bandwidth.


September 13, 2005
@ 05:26 PM

I am proud to announce that we have launched the MSN Developer Center on MSDN. This is culmination of some of the efforts I started driving shortly after writing the blog post MSN Developer Network? where I wrote

Yesterday, in a meeting to hash out some of the details of MSN Spaces API an interesting question came up. So far I've been focused on the technical details of the API (what methods should we have? what protocol should it use? etc) as well as the scheduling impact but completely overlooked a key aspect of building developer platform. I hadn't really started thinking about how we planned to support developers using our API. Will we have a website? A mailing list? Or a newsgroup? How will people file bugs? Do we expect them to navigate to and use the feedback form?

Besides supporting developers, we will need a site to spread awareness of the existence of the API.

After writing that post I started talking to various folks at MSN who were interested in providing APIs for their various services and realized that there was an opportunity for us to come up with a unified developer portal as opposed to a number of disjoint efforts. My argument was that instead of developers having to figure out they need to go to to find out about extending MSN toolbar and to find out about building MSN Virtual Earth mash-ups, we should just have for all of MSN's Web 2.0 efforts. Everyone I talked to thought this made sense and now here we are.

Currently you can find information on extending or building applications with the APIs from Windows Desktop Search, MSN Toolbar,, MSN Virtual Earth, MSN Search, and MSN Messenger. In the near future I will be adding information about the APIs for interacting with MSN Spaces.

In addition to the developer center, we also have MSN Developer Forums where developers can discuss the various MSN APIs and interact with some of the people who work on the technologies.

Of course, this is just the beginning. Over the long term we have a bunch of stuff planned for the dev center including more APIs and more MSN properties joining the Web 2.0 party. This is going to be lots of fun.

PS: Shout outs go out to Jim Gordon, Chris Butler, Seth Demsey, Scott Swanson, Josh Ledgard and a host of others who helped make this a reality.


Categories: MSN

Surprise, surprise. Check out to try out a preview of Microsoft's AJAX framework. From the website

ASP.NET "Atlas" is a package of new Web development technologies that integrates an extensive set of client script libraries with the rich, server-based development platform of ASP.NET 2.0. "Atlas" enables you to develop Web applications that can update data on a Web page by making direct calls to a Web server — without needing to round trip the page. With "Atlas", you can take advantage of the best of ASP.NET and server-side code while doing much of the work in the browser, enabling a richer user experience.

ASP.NET "Atlas" includes:

  • Client script libraries that provide a complete solution for creating client-based Web applications. The client script libraries support object-oriented development, cross-browser compatibility, asynchronous calls to Web services, and behaviors and components for creating a full-featured UI.
  • Web server controls that provide a declarative way to emit markup and client script for "Atlas" features.
  • Web services, such as ASP.NET profiles, that can add useful server-side features to an "Atlas" application.

It's great to see this getting out to developers so quickly. Kudos to Scott Isaacs, Walter Hsueh and the rest of the folks at MSN who worked with the ASP.NET team on this project.


Categories: Web Development

September 13, 2005
@ 03:35 PM

In planning for our future releases, I came up against a design question that I'd like to see solved in future versions of the .NET Framework. The basic scenario is a website that wants to expose a web service using a number of different protocols (SOAP, XML-RPC, JSON, Plain Old XML (POX), etc) without having to write a lot of duplicate code. For example, the Flickr web services expose 3 interfaces for each method (SOAP, XML-RPC and POX).

From my perspective, this is something that should be handled by a protocol agnostic web services stack which is what the Windows Communications Foundation (aka Indigo) is supposed to be. On the other hand, the ASP.NET team's recently announced Atlas project is targetted server-side AJAX development.

What I want to know is basically this, if I want to create web services that utilize both SOAP & JSON does that mean I have to adopt both Indigo and Atlas?

Can some helpful soul at PDC ask this at any sessions on Indigo or Atlas? I guess I can always wait until next week and get the info from the horses mouth but product teams tend to give better answers to external customers than us internal MSFT folks. :)


Since my previous post on the various MSN sessions at PDC, two new ones have finally had their details announced. They are

PRSL02 - Case Study: How Hotmail Used Atlas and ASP.NET to Build a Great User Experience
September 14, 12:30 PM - 1:15 PM
152/153 (Hall F)
Walter Hsueh

Microsoft's Hotmail web application team is developing the successor to Hotmail: a modern webmail experience focused on safety, simplicity, and speed. We will walk you through the scale and performance requirements of the Internet's largest distributed webmail application and show you how building on ASP.NET and Atlas technologies provides the right solution for the problem space. Learn from our experiences and design patterns of how we leveraged the "Atlas" programming model and "Atlas" components to build rich, interactive Web applications.

PRSL04 - MSN: Extending Using Startlets
September 15, 1:00 PM - 1:45 PM
408 AB
Scott Isaacs/ Sanaz Ahari
MSN's Web incubation team is creating a new AJAX-based personalized Web experience at - here is your opportunity to get under the covers and see how we are building this site. allows for consumers to personalize their web experience to the things that matter the most to them. See how we build modules (Startlets) such as the Stock Picker, Weather Picker, and Blogger Map. Learn how to create your own custom Startlets for We will also present how your RSS feed can also define a unique experience when viewed within The team and architect will give you a tour of code you can use today. Join us for lunch and catch the latest wave of innovation from MSN's Web incubation team.

If you are a Web developer attending PDC that is interested in server side or client side AJAX development then you should attend both talks.

Categories: MSN

September 13, 2005
@ 02:18 AM

Shelley Powers has a post entitled Change starts at home where she points out the speaker list of the Our Social World conference is pretty homogenous (white males) and consists of the usual suspects when it comes to geeking about social software. I was quite surprised to see a comment in response to her post which stated

Shelley, you’re totally off the mark here. Firstly, there simply are not that many women working professionally on social software/blogging in the UK...Secondly, the speakers were self-selecting. Geoff who organised it put up a wiki and anyone could put their name down to speak. No women other than myself went to the effort of putting their name down and turning up... Finally, regarding ethnic minorities, you have to remember that the UK is not as ethnically diverse (and that that diversity is not as widely spread out) as the US .

I don't know about the UK but I do know that in the US, there are a lot of women in Social Software yet I keep seeing the same set of [white male] names on the speaker lists of various conferences on the topic. Given that this is the second post I've read today that points out the incongruities in the choices of geeks typically chosen as spokespeople for the social software world (the first was Phil Haack's Where are the Sociologists of Social Software) I decided to write something about it.

Just like with my Women in XML post last year, Shelley's post did make me start thinking about how many women I knew who worked with Social Software whose works I'd rather see presented than at least one of the presentations currently on the roster for the Our Social World conference. Here is my list





These women either are heavily involved in research around the sociological impact of technology and human interaction or actually work on building social software applications used by millions of people. Quite frankly, I'd rather hear any one of them speak than the typical geek you see at the average O'Reilly conference yaking about Social Software.

Unfortunately the people who really do the work that changes the world often get less publicity than the ones who just talk about it.


Categories: Social Software