I mentioned last week that 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. Start.com fundamentally changes this model by turning it on its head. I can create an RSS feed and specify how it should render in Start.com using JavaScript in extension elements which basically makes it a Start.com gadget, no different from the default ones provided by the site. For example, I can create an RSS feed for weekly weather reports and specify that they should rendered as shown below within Start.com

Scott Isaacs gives some descriptions of how the RSS extensions used by Start.com work in his post Declaring Gadgets for Start.com using "RSS". He writes

Introduction to the Gadget Manifest

First, let's look at the Gadget manifest format. For defining manifests, we basically reused the RSS schema.  This format decision was driven by the fact we already have a parser in Start.com's application model for RSS, there is broad familiarity with the RSS format, and I personally did not want to invent yet another schema . While we reused the RSS schema, we do recognize that these are not typical RSS feeds as they are not intended to be consumed and directly rendered by an aggregator. Therefore, we are considering whether we should use a different file extension or root element (e.g., replace RSS with Manifest) but still leverage the familiar tags. For the sake of simplicity, we chose to ship reusing RSS as the format and then listen to the community on how to proceed. We are very open to suggestions.

Looking at the Gadget manifest, we extended the RSS schema with one custom tag, and one custom attribute. We defined those under the binding namespace. Below is a sample Gadget manifest:

<?xml version="1.0"?>
<rss version="2.0" xmlns:binding=" http://www.start.com ">
   <channel>
      <title>Derived Hello World</title>
      <link>http://yourhomepage.com</link>
      <description>A sample hello world binding.</description>
      <language>en-us</language>
      <pubDate>Wed, 27 Apr 2005 04:00:00 GMT</pubDate>
      <lastBuildDate>Wed, 27 Apr 2005 04:00:00 GMT</lastBuildDate>
      <binding:type>Demo.MyHelloWorld</binding:type>
      <item>
         <link>http://siteexperts.com/bindings/MyHello.js</link>
      </item>
      <item>
         <link binding:type="inherit">http://siteexperts.com/bindings/hello.xml</link>
      </item>
      <item>
         <link binding:type="css">http://siteexperts.com/bindings/myHelloWorld.css</link>
      </item>
   </channel>
</rss>

Looking at the Gadget manifest, until we reach an RSS item, the semantics of the existed RSS tags is maintained. The title serves as the Gadget title, link typically points to your home page or page about your Gadgets, description is your Gadget's description, and so on.  The added binding:type element serves as the Gadget class to instantiate from the associated resources.

Looking at each item, we do know that we left off the required title and description since this file is not intended to be directly viewed. However, adding those tags could be useful to help describe the resources being used.

The last change is we added a binding:type attribute to each resource. We currently support three types: script (the default), css, and inherit. Inherit would point to another "RSS" manifest file that would be further consumed.

Assocating a Manifest with a Feed

Start.com supports loading stand-alone Gadgets directly from a manifest. In addition, You can now define a Gadget that presents a custom experience your feed. This is very useful for a number of scenarios...The custom experiences are defined using the "RSS" Manifest format described above. However, since these Gadgets for RSS feeds are driven by the feed itself, we needed to extend traditional RSS with a single extension. This extension associates a manifest with the feed. We created a new channel element, binding:manifest that can be included in any RSS feed. This element specifies the Gadget manifest to use for the feed.

<binding:manifest environment="Start" version="1.0">
  http://siteexperts.com/bindings/rumorcity.xml
</binding:manifest>

We created this element to not be coupled to any single implementation. Hence the required environment element. Aggregators that understand the manifest tag can examine the environment value. If they support the specified environment, they can choose to present the custom experience.

Despite the fact that I kicked off some of the initial discussions with Steve Rider for what are now Start.com gadgets, I haven't paid much attention to the design since Start.com is a work in progress. Based on the current design, I have two primary pieces of feedback.

1. I'd suggest picking a different namespace URI. XML namespace URIs usually point to documentation about the format, in the cases that they don't it is often a cause of consternation amongst developers. For example, most XML namespaces used by Microsoft are from the schemas.microsoft.com domain which often point to schemas for the various Microsoft XML vocabularies. In the cases where they don't it is likely that they will in future. See http://www.google.com/search?q=+site:schemas.microsoft.com+%22schemas.microsoft.com%22 for some examples.

2. If Gadget manifests aren't supposed to be consumed by traditional RSS aggregators then Start.com should not use RSS as it's manifest format. The value of using RSS is that even if a client doesn't understand your extensions then the feed is still useful. Start.com currently breaks that assumption which to me is an abuse of RSS.
   

Scott is currently seeking feedback for the Start.com RSS extensions and I'd suggest that interested parties should post some comments about what they like or dislike so far in response to his blog post.

Update: Since writing this post I've exchanged some mail with the Start.com team and in addition to my feedback we've discussed feedback from folks like Phil Ringnalda and James Snell. The Start.com team used RSS as the gadget manifest file format as an experiment in the spirit of the continuous experiment that is http://www.start.com. Based on the feedback from the community, alternatives will be considered and fully documented when the choices have been made. Given my experience in XML syndication technologies I'll be working with the Start.com team on exploring alternatives to the current techniques used for creating gadget manifests as well as documenting them.

Keep the feedback coming.

 

Recently, Sam Ruby announced that the Atom 0.3 syndication format would be deprecated by the Feed Validator. When I first read his post I half wondered what would happen if someone complained about being told their previously valid feed was no longer valid simply because it was now using an "old" format. This afternoon I found an  email from Donald Knuth (yes, that one) to the www-validator@w3.org mailing list complaining about just that. In his mail note from Prof Knuth, he writes

Dear Validators,

I've been happily using your service for many years --- even before w3c
took it over. I've had a collection of web pages at Stanford since
1995 or so; it now amounts to hundreds of pages, dozens of which have
tens of thousands of hits, several of which have hits in the millions.

Every time I make a nontrivial change, I've been asking the validator
to approve it. And every time, I've won the right to display the
"HaL HTML Netscape checked" logo.

Until today. Alluva sudden you guys have jerked the rug out from
under my feet.

I protest! I feel like screaming! Unfair!

I'm not accustomed to flaming, but I have to warn you that I am just
now more than a little hot under the collar and trying not to explode.

For years and years, I have started each webpage with the formula
I found in the book from which I learned HTML many years ago, namely
  <!DOCTYPE HTML PUBLIC "-//Netscape Comm. Corp.//DTD HTML//EN">

Today when I tried to validate a simple edit of one page, I found
that your system no longer is happy --- indeed, it hates every
one of my webpages. (If you need a URL, Google for "don" and take
the topmost page, unless you are in France.)

For example, it now finds 19 errors on my home page, which was 100%
valid earlier this month. The first error is "unknown parse mode!".
Apparently Stanford's Apache server is sending the page out as text/html.
You are saying text/html is ambiguous, but that you are going to continue
as if it were SGML mode. Fine; but if I get the Stanford folks to
change the MIME type to SGML mode, I'll still have 18 more errors.

The next error is "no DOCTYPE found". But guys, it is there as
plain as day. Henceforth you default to HTML 4.01 Transitional.

Then you complain that I don't give "alt" specifications with
any of the images. But the Netscape DTD I have used for more
than 3000 days does not require it.

Then you don't allow align="absmiddle" in an image.

I went to your help page trying to find another DTD that might
suit. Version 2.0 seemed promising; but no, it failed in other
ways --- like it doesn't know the bgcolor and text color attributes
in the <body> of my page.

Look folks, I know that software rot (sometimes called "progress")
keeps growing, and backwards compatibility is not always possible.
At one point I changed my TeX78 system to TeX82 and refused to
support the older conventions.

But in this case I see absolutely no reason why system people who
are supposedly committed to helping the world's users from all
the various cultures are suddenly blasting me in the face and
telling me that you no longer support things that every decent
browser understands perfectly well.

To change all these pages will cost me a week's time. I don't
want to delay The Art of Computer Programming by an unnecessary week;
I've been working on it for 43 years and I have 20 more years of work
to do, and who knows what illnesses and other tragedies are in store.
Every week is precious, especially when it seems to me that there
is no valid validation reason for a competent computer system person
to be so fascistic. For all I know, you'll be making me spend
another week on this next year, and another the year after that.

So, my former friends, please tell me either (i) when you are
going to fix the problem, or (ii) who is your boss so that I
can complain at a higher level.

Excuse me, that was a bit flamey wasn't it, and certainly egocentric.
But I think you understand why I might be upset.

Sincerely, Don Knuth

 

I've been a long time skeptic when it comes to RDF and the Semantic Web. Every once in a while I wonder if perhaps what I have a problem with is the W3C's vision of the Semantic Web as opposed to RDF itself. However in previous attempts to explore RDF I've been surprised to find that its proponents seem to ignore some of the real world problems facing developers when trying to use RDF as a basis for information integration.

Recently I've come across blog posts by RDF proponents who've begun to question the technology. The first is the blog post entitled Crises by Ian Davis where he wrote

We were discussing the progress of the Dublin Core RDF task force and there were a number of agenda items under discussion. We didn’t get past the first item though - it was so hairy and ugly that no-one could agree on the right approach. The essence of the problem is best illustrated by the dc:creator term. The current definition says An entity primarily responsible for making the content of the resource. The associated comments states Typically, the name of a Creator should be used to indicate the entity and this is exactly the most common usage. Most people, most of the time use a person’s name as the value of this term. That’s the natural mode if you write it in an HTML meta tag and it’s the way tens or hundreds of thousands of records have been written over the past six years...Of course, us RDFers, with our penchant for precision and accuracy take issue with the notion of using a string to denote an “entity”. Is it an entity or the name of an entity. Most of us prefer to add some structure to dc:creator, perhaps using a foaf:Person as the value. It lets us make more assertions about the creator entity.

The problem, if it isn’t immediately obvious, is that in RDF and RDFS it’s impossible to specify that a property can have a literal value but not a resource or vice versa. When I ask “what is the email address of the creator of this resource?” what should the (non-OWL) query engine return when the value of creator is a literal? It isn’t a new issue, and is discussed in-depth on the FOAF wiki.

There are several proposals for dealing with this. The one that seemed to get the most support was to recommend the latter approach and make the first illegal. That means making hundreds of thousands of documents invalid. A second approach was to endorse current practice and change the semantics of the dc:creator term to explictly mean the name of the creator and invent a new term (e.g. creatingEntity) to represent the structured approach.
...
That’s when my crisis struck. I was sitting at the world’s foremost metadata conference in a room full of people who cared deeply about the quality of metadata and we were discussing scraping data from descriptions! Scraping metadata from Dublin Core! I had to go check the dictionary entry for oxymoron just in case that sentence was there! If professional cataloguers are having these kinds of problems with RDF then we are fucked.

It says to me that the looseness of the model is introducing far too much complexity as evidenced by the difficulties being experienced by the Dublin Core community and the W3C HTML working group. A simpler RDF could take a lot of this pain away and hit a sweet spot of simplicity versus expressivity.

Ian Davis isn't the only RDF head wondering whether there is too much complexity involved when trying to use RDF to get things done. Uche Ogbuji also has a post entitled Is RDF moving beyond the desperate hacker? And what of Microformats? where he writes

I've always taken a desperate hacker approach to RDF. I became a convert to the XML way of expressing documents right away, in 1997. As I started building systems that managed collections of XML documents I was missing a good, declarative means for binding such documents together. I came across RDF, and I was sold. I was never really a Semantic Web head. I used RDF more as a desperate hacker with problems in a fairly well-contained domain.
...
I've developed an overall impression of dismay at the latest RDF model semantics specs. I've always had a problem with Topic Maps because I think that they complicate things in search of an unnecessary level of ontological purity. Well, it seems to me that RDF has done the same thing. I get the feeling that in trying to achieve the ontological purity needed for the Semantic Web, it's starting to leave the desperate hacker behind. I used to be confident I could instruct people on almost all of RDF's core model in an hour. I'm no longer so confident, and the reality is that any technology that takes longer than that to encompass is doomed to failure on the Web. If they think that Web punters will be willing to make sense of the baroque thicket of lemmas (yes, "lemmas", mi amici docte) that now lie at the heart of RDF, or to get their heads around such bizarre concepts as assigning identity to literal values, they are sorely mistaken. Now I hear the argument that one does not need to know hedge automata to use RELAX NG, and all that, but I don't think it applies in the case of RDF. In RDF, the model semantics are the primary reason for coming to the party. I don't see it as an optional formalization. Maybe I'm wrong about that and it's the need to write a query language for RDF (hardly typical for the Web punter) that is causing me to gurgle in the muck. Assuming it were time for a desperate hacker such as me to move on (and I'm not necessarily saying that I am moving on), where would he go from here?

Uche is one of the few RDF heads whose opinions seem grounded in practicality (Joshua Allen is another) so it is definitely interesting to see him begin to question whether RDF is the right path.

I definitely think there is some merit to disconnecting RDF from the Semantic Web and seeing if it can hang on its own from that perspective. For example, XML as a Web document format is mostly dead-on-arrival but it has found a wide variety of uses as a general data interchange format instead. I've wondered if there is similar usefulness lurking within RDF once it loses its Semantic Web baggage.

 

The announcements from about Microsoft's Linq project just keep getting better and better. In his post XML, Dynamic Languages, and VB, Mike Champion writes

Thursday at PDC saw lots of details being put out about another big project our team has been working on -- the deep support for XML in Visual Basic 9...On the VB9 front, the big news is that two major features beyond and on top of LINQ will be supported in VB9:

"XML Literals" is  the ability to embed XML syntax directly into VB code. For example,

Dim ele as XElement = <Customer/>

Is translated by the compiler to

Dim ele as XElement =  new XElement("Customer")

The syntax further allows "expression holes" much like those in ASP.NET where computed values can be inserted.

"Late Bound XML" is the ability to reference XML elements and attributes directly in VB syntax rather than having to call navigation functions.  For example

Dim books as IEnumerable(Of XElement) = bib.book

Is translated by the compiler to

Dim books as IEnumerable(Of XElement) = bib.Elements("book")

 We believe that these features will make XML even more accessible to Visual Basic's core audience. Erik Meijer, a hard core languages geek who helped devise the Haskell functional programming language and the experimental XML processing languages X#, Xen, and C-Omega, now touts VB9 as his favorite.

Erik Meijer and I used to spend a lot of time talking about XML integration into popular  programming languages back when I was on the XML team. In fact, all the patent cubes on my desk are related to work we did together in this area. I'm glad to see that some of the ideas we tossed around are going to make it out to developers in the near future. This is great news.

 

A few months ago in my post GMail Domain Change Exposes Bad Design and Poor Code, I wrote Repeat after me, a web page is not an API or a platform. It seems some people are still learning this lesson the hard way. In the post The danger of running a remix service Richard MacManus writes

Populicio.us was a service that used data from social bookmarking site del.icio.us, to create a site with enhanced statistics and a better variety of 'popular' links. However the Populicio.us service has just been taken off air, because its developer can no longer get the required information from del.icio.us. The developer of Populicio.us wrote:

"Del.icio.us doesn't serve its homepage as it did and I'm not able to get all needed data to continue Populicio.us. Right now Del.icio.us doesn't show all the bookmarked links in the homepage so there is no way I can generate real statistics."

This plainly illustrates the danger for remix or mash-up service providers who rely on third party sites for their data. del.icio.us can not only giveth, it can taketh away.

It seems Richard Macmanus has missed the point. The issue isn't depending on a third party site for data. The problem is depending on screen scraping their HTML webpage. An API is a service contract which is unlikely to be broken without warning. A web page can change depending on the whims of the web master or graphic designer behind the site.

Versioning APIs is hard enough, let alone trying to figure out how to version an HTML website so screen scrapers are not broken. Web 2.0 isn't about screenscraping. Turning the Web into an online platform isn't about legitimizing bad practices from the early days of the Web. Screen scraping needs to die a horrible death. Web APIs and Web feeds are the way of the future.

 

BusinessWeek has a cover story titled Troubling Exits at Microsoft which contains some excerpts from my blog. The relevant excerpt is

While Microsoft's internal reformers don't directly criticize Gates, they're frustrated with the sluggish pace of product development. As the company's chief software architect, Gates bears that responsibility. He's the author of a strategy called "integrated innovation." The idea is to get Microsoft's vast product groups to work closely together to take advantage of the Windows and Office monopolies and bolster them at the same time. But with so much more effort placed on cross-group collaboration, workers spend an immense amount of time in meetings making sure products are in sync. It "translates to more dependencies among shipping products, less control of one's product destiny, and longer ship cycles," writes Dare Obasanjo, a program manager in Microsoft's MSN division, on his blog.

To shake Microsoft out of its malaise, radical surgery may be in order.

Wow. Almost every month I am reminded that the stuff I write here can and is read by journalists. At the very least Jon Udell and Steve Gillmor seem to be somewhat regular readers given the number of times I've been quoted by them. This does make it hard for my blog to be as 'personal' as I want it to be.

This is the second time this year my blog has been quoted in a major business paper. The first was the mention in the Wall Street Journal over a back and forth blog discussion between myself, Adam Bosworth and Krzysztof Kowalczyk about Google's contributions to Open Source. Since then Google has launched efforts like the Summer of Code contest and the Google Code website as ways to contribute back to the Open Source movement which has benefitted them so much.

I hope we'll see as much positive change within Microsoft in the future. It seems that we are already trying to move in the right direction with the recent stories about Microsoft's plans to overhaul its development strategy.

 

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 "http://example.com" namespace

   XElement contacts = new XElement("{http://example.com}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
                                                               {Name="Patrick Hines",
                                  PhoneNumbers = new string[]
                                                                                       {"206-555-0144", "425-555-0145"}
                                  },
                          new Person {Name="Gretchen Rivas",
                                      PhoneNumbers = new string[]
                                                                                       {"206-555-0163"}
                                  }
                         };

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

   Console.WriteLine(contacts);

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

   foreach (x in contact.Elements()) {
               Console.WriteLine(x);
   }

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

   foreach (x in contact.Elements("phone")) {
               Console.WriteLine(x);
   }

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

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

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");
   firstPhone.AddAfterThis(mobilePhone);

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

    contact.Elements("phone").Remove();

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

    contacts.Element("contact").Element("address").RemoveContent();

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

    contact.Element("phone").ReplaceContent("425-555-0155");

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"),
                      "206-555-0144"
                ),
                new XElement("phone",
                      new XAttribute("type", "work"),
                      "425-555-0145"
                )
          );

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)p);
       }

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

    contact.Elements("phone").First().Attribute("type").Remove();

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",
                c.Element("name"),
                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") == "WA"
    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.

 

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 Start.com 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 Start.com by Sanaz Ahari

Start.com was initially released on February 2005, on start.com/1 – since then we’ve been innovating regularly (start.com/2, start.com/3, start.com and start.com/pdc) 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 start.com experience. You can read more it here: http://start.com/developer. 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 start.com, 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 Start.com 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. Start.com fundamentally changes this model by turning it on its head. I can create a custom RSS feed and specify how it should render in Start.com using JavaScript which basically makes it a Start.com 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.

 

Start.com has always been an innovative service but today's announcements have kicked it up a notch. In his post Start.com: A Preview of Web 3.0, Scott Isaacs writes

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

• DHTML-based Gadgets
  Start.com consumes DHTML-based components called Gadgets. These Gadgets can be created by any developer, hosted on any site, and consumed into the Start.com 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. Start.com 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
  Start.com 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 Start.com model since its inception (how do you think they released new features every week?). By opening up Start.com, we have removed the boundaries around Start.com features and experiences. The community of developers and publishers can now define and control the richness of the Start.com 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 Start.com, the developer community can preview MSN's client technology and infrastructure. At Start.com/Developer, 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 Start.com. 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.

 

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 http://msdn.microsoft.com/netframework/future/linq

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 XML.com 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?