Steve Hooker has a post entitled Microsoft's Spaces: are they blogs?  where he writes

Certainly, they are blogs, at least for Joe Sixpack, but why did they call them 'Spaces'? My guess is that they're going to take them deeper into Microsoft land, and the term 'blog' won't fit later. Already they're locked into MS's instant message app, Messager and their authentication system Passport.

I'm unclear as to why Steve calls the requirement of having a user account to create a Space "lock in" especially since every blog hosting service requires some form of user account be it Xanga, LiveJournal, TypePad, or Blogger. MSN Spaces has the advantage that you can use this same account to access multiple MSN services including MSN Messenger. This is no different than the fact that I have a single login to access all of Yahoo's services.

As to why they are called "spaces" as opposed to "blogs" it is because we believe there is more to sharing one's experiences online than your online journal. People want to share their thoughts, their favorite music, their favorite books, pictures of their loved ones and so on. It isn't just  posting your thoughts and experiences in the reverse chronological order which is what typically defines a "weblog". It's supposed to be a person's personal space online which was the original vision of personal publishing on the Web which spawned the personal homepage revolution a couple of years ago. Weblogs are the next iteration of that vision and we expect MSN Spaces to be the refinement of that iteration.

I've seen a number of people ask if MSN Spaces supports any web service APIs such as the Blogger API or MetaWeblog API that allow users to post to their blog from applications such as MarsEdit, BlogJet and w:bloggar.  This question has been asked in blog posts by a number of people including Robert Scoble, Don Smith and Roland Tanglao. Like every question there's a short answer and a long answer.

Short Answer: There is currently no support for any web service APIs for managing ones Space. We are investigating the feasibility of supporting a web service API which enables our users to manage their Space while not having to compromise on security which unfortunately is currently the practice in the blogging world.  

Long Answer: I listed the problems with the current crop of blog posting APIs such as the Blogger API and MetaWeblog API  in my post from a year and a half ago What's Wrong with the MetaWeblog API? . The main issues for us working on MSN Spaces are  

1. Security: The MetaWeblog API has no concept of security. Passwords are sent in plaintext as parameters to XML-RPC functions (i.e. they are sent in plain text on the wire as part of the XML message).
2. Limited Functionality: The MetaWeblog API only allows one to either post and edit blog entries, fetch information about a specific user or change the website template. This is a drop in the bucket considering all the things one would like to do with a weblog engine which can be supported by the engine.

The security issue is a big problem and we do not plan to compromise on it. Although it may be satisfactory for certain services to exchange user's passwords in plain text where they can be sniffed by malicious third parties we don't want the Passport accounts of our user's exposed in such an insecure manner. This basically means we can't plug into the ecosystem of tools and services built around blog posting APIs today.  

Already the current beta version of MSN Spaces has more functionality than is exposed by APIs such as the MetaWeblog API. For example, it would be difficult to imagine how one would manage their music list with just that API. Add to that the fact that we are planning to add more features in future versions that also have no useful analog in that API.

I plan to present 3 choices to folks at work on what we should do in this regard. The choices I see in order of preference would be

1. Support Blogger/MetaWeblog API over HTTPS/SSL: This would involve the most minimal change to various blog posting tools to support MSN Spaces yet would give our users the security they desire. Unfortunately it doesn't solve the problem that these APIs don't expose all the functionality of an MSN Space.
2. Support an MSN Spaces specific API over HTTPS/SSL:  This would allow us to build an API specifc to our service such as has been done with the MovableType API or the LiveJournal API . The downside is that it would mean developers would have to do a lot more work to suupport our service but would expose richer functionality than if we just supported the Blogger/Metaweblog APIs. This would lead to less tool support but I suspect the most popular tools would support our API. 
3. Support the Atom API over HTTPS/SSL: The IETF's Atom Working Group is working on a new common  API for blog posting which they hope will replace the aforementioned blog posting APIs. I have questions about their delivery timeframe given that its been over a year and a half since Sam Ruby kicked of the Atom effort  and although their schedule has them shipping the spec in a few months they are still having debates on fundamentals such as whether the Atom protocol should be based on WebDAV or not. Having worked on the XML team at Microsoft and watching I have seen what happened when we spent years working on technologies like XInclude & XQuery which are in active discussion only for them to drag out so long that they couldn't fit in our ship schedule so we cut them thus wasting the effort.  Secondly, still has the problem that it won't expose all the functionality of an MSN Space. I don't have much faith in this option but have put it on the list for completeness.

I should note that there is also the question of whether it makes business sense to do support blog posting APIs. Mike will be the one making the business case pitch to folks over here while I'll be making the technical pitches. It would be interesting to know what percentage of users actually use a rich client versus using the Web interface for editing their blogs in existing systems.

Anyway, your thoughts and feedback are welcome. I'd especially love to hear from authors of blog posting tools.  

By now it's common knowledge that MSN Spaces became widely available to the general public today. As someone who's currently working on the next iteration of Spaces I've already had time to excercise the existing realease and I've got to day I like it a lot. Below is the list of top 5 things I like about Spaces

1. Integrated Photo Album: If you visit Carnage4Life's Space you don't just get to see my blog but also a slideshow of various RSS Bandit screenshots I uploaded a few days ago.

2. Integrated Music Lists:  I get to share my taste in music via music lists where each song is hyperlinked to search MSN Music so one can hear a sample of the music I like. For lazy people like me you can just upload a Windows Media player playlist to create a music list.

3. MSN Messenger Integration: Words don't do it justice. Here's a screenshot of me viewing Mike Torres' contact card.  Here's a screenshot of my contact card. Yes, the rumors were right. You can post to your blog directly from MSN Messenger.

4. Access Control: One can specify the level of access they want for their blog. You can choose to make a blog public, private or only accessible by people on your MSN Messenger Allow List. Your Allow List is a list of everyone who you've allowed to see your online presence and IM you via MSN Messenger. This should be everybody on your buddy list and everyone who's asked to put you on their buddy list and you've accepted. This allows you to create a blog that is only accessible by people in your immediate circle of friends and family which for most people are the only ones you want reading your blog or viewing your photos .
   
   It should be noted that in a number of markets the permissions on your Space default to "Only allow people in my MSN Messenger Allow List view my Space". So it is best to check http://spaces.msn.com/members/[yourblogname]/PermissionSettings.aspx and ensure that you have specified the level of access control you are comfortable with.

5. The Price: It's free. Completely and utterly free of charge.  

According to the Microsoft press release MSN Introduces New Communication Service That Enables Blogging, Picture Sharing and More  we find out

MSN Spaces: More Than a Blog

The MSN Spaces beta version is a free service available in 14 languages and 26 markets worldwide. MSN Spaces was designed to make it easy for consumers to create and maintain a personal Web site, bringing the power and benefits of blogging to millions of Internet users, regardless of their level of technical expertise. More than a blogging tool, MSN Spaces is a dynamic online scrapbook where consumers can share photo albums, personal music lists and more. And more than an ordinary personal Web site, through seamless integration with MSN Messenger and MSN Hotmail, MSN Spaces will automatically notify online contacts when a person's Space has been updated so his or her online community knows when it is time to pay a visit. People can sign up for MSN Spaces through MSN Messenger or by going to http://spaces.msn.com. Key features of the service include the following:

• Control your Space. Consumers can choose the people who visit their Space through three levels of permissions: public, MSN Messenger contacts only or private.
• Use pictures and music to say more. MSN Spaces enable consumers to easily display their pictures via a photo album slide show. Consumers can easily share playlists through their Space with Microsoft® Windows Media® technologies. With just two clicks, people can sample or purchase a song on someone's playlist through MSN Music**.
• Create an extension of yourself. Contact Cards - a new addition to MSN Messenger and Hotmail - are windows into a consumer's Space, mirroring its look and the most recent information posted. MSN Spaces also supports RSS, so consumers can publish their Space to others by way of RSS viewers and aggregators - including My MSN, coming soon.
• Post remote updates. Consumers can post updates to their Space remotely via e-mail or a mobile phone.
• Make it your own. Fifteen custom backgrounds and five layout templates give consumers a way to quickly customize and personalize their Space.

MSN Messenger: More Expressive Than Ever

Available in 26 languages, the public beta release of MSN Messenger builds on the popular IM service which supports more than 145 million active users worldwide each month, and offers consumers new ways to express themselves online and personalize their instant messaging experience. Available for download at http://messenger.msn.com/beta, the beta release of MSN Messenger will give consumers a taste of what's to come with the final release, expected next year. Features in the MSN Messenger 7.0 beta enable consumers to do the following:

• Get attention. Consumers can reach out to friends and family by sending a "Nudge," an alert that shakes the contact's conversation window with an audible notification, or a "Wink," animated pictures that include sound and that can be virtually "thrown" onto the screen of a contact's Internet message (IM) window. New emoticons, backgrounds and theme packs from Microsoft Corp., including advertiser-sponsored packs such as for "Halo® 2",* round out the experience.
• Stay connected. Through integration with MSN Messenger, consumers can automatically let their contacts know that they have updated their MSN Space. The MSN Messenger Contact icon "gleams" when an update is made, notifying others to visit the Space via the Contact Card.
• Access the Web anywhere. MSN Web Messenger, shipping in 25 markets and 15 languages, enables consumers to access their MSN Messenger account and contacts from virtually any PC with an Internet connection.
• Choose your online status. The beta release of MSN Messenger gives consumers more control over how they're seen online by enabling them to choose their availability status before logging into Messenger.

MSN Hotmail: Bringing It All Together

MSN Hotmail, the largest free Web e-mail system in the world with more than 187 million active accounts, rounds out the trio of free, integrated communication services. MSN Hotmail recently introduced 250MB inboxes to new consumers in nine markets and launched a photo upload tool for all consumers to make it easier for them to share pictures online. The beta versions of MSN Spaces and MSN Messenger help give consumers even more ways to communicate and share through MSN Hotmail, including these:

• View online status anywhere. Through integration between MSN Hotmail and MSN Web Messenger, in select markets, consumers are able to see Messenger availability status even on PCs that don't have MSN Messenger client software.
• Learn more about Contacts. MSN Hotmail consumers who have an MSN Spaces site will have a Contact Card visible in the Hotmail address book, providing friends, family and other online contacts with one-click access to their Spaces site.

Now that we've finally shipped I'll start blogging more about what we're doing at MSN with regards to Spaces et al. You might also want to check out my blog on MSN Spaces at http://spaces.msn.com/members/carnage4life

Don Smith has a post entitled One parameter to rule them all: Part 2 where he writes

In my post yesterday, I recommended that Web Service operations should only have a single input parameter rather than multiple for the sake of versioning.
...
Suppose we want to send version information to the operation. In the example above, there's nowhere for it to go. "Why would we want to send version information to the operation?" Because as we version the operation, we should include version information so it's obvious what changed in each version. We can't get that information by simply adding new parameters to the method signature. I'm not going to go into it here (I will in my article) but there is a approach Doug talks about here about how to version datatypes that contain this version metadata. By using a single uber-parameter, we can include the traditional parameters as well as any metadata we need to send like version infomation. Then, instead of having to check for nulls, we can switch on the version metadata.

To me this seems to imply a simplistic view of the problems inherent in versioning XML Web Service end points and also pushes unnecessary API clutter on users of the end point. So imagine that in v1 of the end point, the GetTemp method takes a city and zip code then in v2 an optional zip code is added. To me I'd rather have developers know they can either call

MyService.GetTemp("Redmond", "WA");
MyService.GetTemp("Redmond", "WA", "98052"):

instead of

MyService.GetTemp(new TemperatureRequest("1.0", "Redmond", "WA"));
MyService.GetTemp(new TemperatureRequest("2.0", "Redmond", "WA", "98052"));

For one, the latter is less straightforward than the former. Also the developer has to know how to manage interdependencies between properties of the TemperatureRequest that are set if there are any that are mutually exclusive, know which properties are required and whether to initialize primitive values in the object to defaults without any help from the API. Of course, all this will be in the documentation but APIs should be designed so their behavior is intuiive not so that one is required to read all the documentation before one can get things done.

The other reason I like the former is that it carries the impression that the XML Web Service end point is unchanging while the latter does not. This is not really a tachnical reason but it makes it less likely that the designer of the service will change the behavior of that particular method at specific end point if its contract never changes.

My dayjob now involves designing XML Web Service end points so you'll probably start seeing more XML Web Services related posts from me.

Tim Bray has a post entitled More Relax where he writes

I often caution people against relying too heavily on schema validation. “After all,” I say, “there is lots of obvious run-time checking that schemas can’t do, for example, verifying a part number.” It turns out I was wrong; with a little extra work, you can wire in part-number validation—or pretty well anything else—to RelaxNG. Elliotte Rusty Harold explains how. Further evidence, if any were required, that RelaxNG is the world’s best schema language, and that anyone who who’s using XML but not RelaxNG should be nervous.

Elliote Rusty Harold's article shows how to plug in custom datatype validation into Java RELAX NG validators. This enables one to enforce complex constraints on simple types such as such as "the content of an element is correctly spelled, as determined by consulting a dictionary file" or "the number is prime" to take examples from ERH's article. 

Early in the design of the version 2.0 of the System.Xml namespace in the .NET Framework we considered creating a System.Xml.IXmlType interface. This interface would basically represent the logic for plugging one's custom types into the XSD validation engine. After a couple of months and a number of interesting discussions between myself, Joshua and Andy we got rid of it.

There were two reasons we got rid of this functionality. The simple reason was that we didn't have much demand for this functionality. Whenever we had people complaining about the limitations of XSD validation it was usually due to its inability to define co-occurence constraints (i.e. if some element or attribute has a certain value then the expected content should be blah)  and other aspects of complex type validation than needing more finer grained simple type validation. The other reason was that the primary usage of XSD for many of our technologies is primarily as a type system not as a validation language. There's already the fact that XSD schemas are used to generate .NET Framework classes via the System.Xml.Serialization.XmlSerializer and relational tables via the System.Data.DataSet. However there were already impedence mismatches between these domains and XSD, for example if one defined a type as xs:nonNegativeInteger this constraint was honored in the generated C#/VB.NET classes created by the XmlSerializer or in the relational tables created by the DataSet. Then there was the additional wrinkle that at the time we were working on XQuery which used XSD as its typoe system and we had to factor in the fact that if people could add their own simple types we didn't just have to worry about validation but also how query operators would work on them. What would addition, multiplication or subtraction of such types mean? How would type promotion, casting or polymorphism work with some user's custom type defined outside the rules of XSD?

Eventually we scrapped the class as having too much cost for too little benefit.

This reminds me of Bob DuCharme's XML 2004 talk Documents vs. Data, Schemas vs. Schemas where he advised people on how to view RELAX NG and XSD. He advised viewing RELAX NG as a document validation language and considering XSD as a datatyping language. I tend to agree although I'd probably have injected something in there about using XSD + Schematron for document validation so one could get the best of both worlds.  

In Jeremy Zawodney's post Are bloggers really that dumb? he writes

I'm not sure if I should be insulted, disappointed, or both. There's a lot of noise out there right now about some dummy data that ended up the Target.com website. Steve Rubel goes so far as to call this a PR crisis in the blogosphere. Even Scoble is complaining.

Jesus Fu@%ing Christ, people. It's a stupid mistake. Are we too screwed up to realize that companies are composed of people and that people sometimes make mistakes? I don't know about you, but I see really big differences between this and the Kryptonite "pick a lock with a ball point pen" crisis. (Hint: It actually was a crisis.)

Any regular reader of Boing Boing has seen this issue before. First it was the Target sells "anal massage" hubbub which turned out to be the result of the fact that Target.com basically mirrors content from Amazon.com but leaves off significant identifying information. Now it's the fact that Target.com is mirroring the page for the book 'Marijuana' published by Rosen Publishing. I guess bloggers are hungry to be the next one who discovers a scandal as juicy as the Trent Lott or Dan Rather fiascos.

Before Jay-Z: Independent Women & Bills Bills Bills

After Jay-Z: Cater 2 U

Several months ago I wrote a draft spec entitled Synchronization of Information Aggregators using Markup (SIAM) which was aimed at providing a lightweight mechanism for aggregators to synchronize state across multiple machines. There was a flurry of discussion about this between myself and a number of other aggregator authors on the [now defunct] information_aggregators mailing list.

However although there was some interest amongst aggregator authors, there wasn't much incentive to implement the functionality for a number of reasons. The reasons range from the fact that it makes it easier for users to migrate aggregators which payware aggregator authors aren't enthusiastic about to the fact that there was no server side infrastructure for supporting such functionality. Ideally this feature would have been supported by a web service end point exposed by a person's weblog or online aggregator. So not much came of it.

Since then I've implemented syncing in RSS Bandit in an application specific manner. So also have the authors of Shrook and NewsGator. There is also the Bloglines Sync API which provides a web service end point to doing limited syncing of feed state whose limitations I pointed out in my post Thoughts on the Bloglines Sync API.

This post is primarily meant to answer questions asked by Dmitry Jemerov, the creator of Syndirella who is now the dev lead for JetBrains' Omea Reader.

This morning I updated the RSS Bandit road map. Mostly we punted a bunch of low priority features to a future release codenamed 'Nightcrawler'. We also took one or two features out of the 'Wolverine' release. The current plan is to ship a beta of 'Wolverine' next month with the big features being the ability to delete items, newspaper views that are 100% compatible with FeedDemon Newspapers and being able to read & post to USENET newsgroups. Afterwards a final version will show up at the end of January or early in February at the latest.

There are also dozens of bug fixes in the 'Wolverine' release. Thanks a lot to the numerous users who took the time to submit bug reports and have been patiently waiting for a release with their fixes. We are now approaching the end game, a lot of the hard work's been done in the underlying infrastructure and the rest of the work left is fairly straightforward.