I'm in the end stages of doing the spec work for the various components in the System.Xml namespace  I am responsible for in the Whidbey betas. After the 4th of July holidays we plan to start doing initial brain storming for what feature work we should do in Orcas/Longhorn. I thought it would be valuable to have various users of XML in the .NET Framework suggest what they'd like us to do in the Orcas version of System.Xml. What changes would people like to see? For example, I'm putting Schematron and XPathReader on the 'nice to have' list. No idea is too unconventional since this is the early brainstorming and prototyping phase.

Caveat: The fact that a technology is mentioned as being on our 'nice to have' list or is suggested in a comment to this post is not an indication that it will be implemented in future versions of the .NET Framework.

Few things are as nice as spending all day writing about XML technologies while sipping Belvedere and listening to G-Unit mix tapes interspersed with Bon Jovi's Crossroad album.

Definitely a good day.

From an E! Online article entitled Method Man Raps Fox

The show debuted last Wednesday to an audience of 8 million--a decent showing for a summer series. But critics assailed the sitcom as nothing more than a collection of racial stereotypes.

Method Man says that while the urban comedy retains a certain hip-hop flavor, it's doesn't jibe with the original subversive vision he and Method & Red's producers intended. Aside from the watered-down subject matter, Method Man lashed out at "lame jokes" that have managed to find their way into scripts and he bemoaned the use of a laugh track, which he said he never agreed to.
...
Method launched into his tirade against the Man after hearing an acting coach on local L.A. radio who said the duo's show smacked of "coonery," i.e., the racial stereotypes prevalent in era of Jim Crow, and criticism from such outlets as BET.com, which labeled Method & Red "unfunny" and attacked it for aiding a "downward spiral in black entertainment" by offering "a benign buffoonish broth ready for mainstream consumption."

"I'm no coon," the Soul Plane star vented. "I'm being criticized by people who have never set foot in the ghetto, who have never put up a brick inside the ghetto. I'm from the ghetto. We can't all be the Cosbys. There needs to be a yin and yang as far as what is shown of black people on television. But I don't want us to be used as a scapegoat for their crusades."

Everytime I've seen ads for this shitty show I've cringed. Movies like Soul Plane and Method & Red remind me a lot of Chris Rock's famous Niggas vs. Black People skit. I can't wait for this idiotic show to get cancelled.

Dave Winer recently wrote

We added a link to a page of encoding examples for descriptions, under Elements of <item>. The change is also noted on the Change Notes page.

I was one of the people that gave feedback on making this clarification to the RSS 2.0 specification and I'm glad it's made it in. Funny enough, not even a week goes before I've had a need to forward the link to an RSS feed producer explaining how to properly escape the content in <description> elements. In this case it was the Microsoft Research RSS feeds. Its pretty clear that this clarification was needed if the folks at MSR didn't get it right the first time they took a shot at it.

From the Showbox calendar

Friday June 25th - House of Blues presents D12 with SLUM VILLAGE and BONE CRUSHER and KING GORDY. $35.00 advance and day of show at TicketsWest and all outlets. Doors at 6PM. All ages. DRESSCODE ENFORCED!

I was planning to be out of town that day but this is a very, very tempting reason to hang around the S-town for an extra day or so. 

The folks at MSDN Chats have organized an online chat session on C# and XML for next month. The participants on the Microsoft side should include myself, Mark Fussell, Erik Meijer, Neetu Rajpal and couple of folks from the C# team. If you'd like to talk to us about topics surrounding XML and C# then log on to the XML and C# chat session at the following time

July 8, 2004
1:00 - 2:00 P.M. Pacific time
4:00 - 5:00 P.M. Eastern time
20:00 - 21:00 GMT

Event Reminders
Add to Outlook Calendar
Tell a Friend

On a side note, am I the only one that thinks the MSDN Chats site is crying out for an RSS feed? I definitely would love to add it to the subscriptions list in my favorite news aggregator.

I read Joel Spolsky's How Microsoft Lost the API War yesterday and found it pleasantly coincidental. Some of the issues Joel brings are questions I've begun asking myself and others at work so I definitely agree with a lot of the sentiments in the article. My main problem with Joel's piece is that it doesn't have a central theme but instead meanders a little and lumps together some related but distinct issues. From where I sit, Joel's article made a few different major & minor points which bear being teased out and talked about separately. The points I found most interesting were

Major Points

1. The primary value of a platform is how productive it makes developers, its ubiquity and how much of a stable environment it provides for them over time. Microsoft's actions in how has released both the .NET Framework and its upcoming plans for Longhorn run counter to this conventional wisdom.
2. Microsoft used to be religious about backwards compatibility, now it no longer is.

Minor Points 

1. The trend in application development is moving to Web applications instead of desktop applications.
2. A lot of developers using the .NET Framework use ASP.NET, client developers haven't yet embraced the .NET Framework.
3. The primary goal of WinFS (making search better)  can be acheived by less intrusive, simpler mechanisms.

So now to dive into his points in more detail.

.NET and Longhorn as Fire & Motion

The primary value of a platform is how productive it makes developers, its ubiquity and how much of a stable environment it provides for them over time. Microsoft's actions in how has released both the .NET Framework and its upcoming plans for Longhorn run counter to this conventional wisdom.

Joel approaches this point from two angles. First of all he rhapsodizes about how the Windows team bends over backwards to achieve backwards compatibility in their APIs even when this means keeping bug compatibility with old versions or adding code to handle specific badly written applications . This means users can migrate applications from OS release to OS release thus widening the pool of applications that can be used per OS. This is in contrast to the actions of competitors like Apple. 

Secondly, he argues that Microsoft is trying to force too many paradigm shifts on developers in too short a time.  First of all, developers have to make the leap from native code (Win32/COM/ASP/ADO) to managed code (ASP.NET/ADO.NET) but now Microsoft has already telegraphed that another paradigm shift is coming in the shape of Longhorn and WinFX. Even if you've made the leap to using the .NET Framework, Microsoft has already stated that technologies in the next release of the .Net Framework (Winforms, ASP.NET Web Services) are already outclassed by technologies in the pipeline (Avalon, Indigo). However to get these later benefits one not only needs to upgrade the development platform but the operating system as well. This second point bothers me a lot and I actually shot a mail to some MSFT VPs about 2 weeks ago raising a similar point with regards to certain upcoming technologies. I expected to get ignored but actually got a reasonable response from Soma with pointers on folks to have followup discussions with. So the folks above are aware of the concerns in this space. Duh!

The only problem I have with Joel's argument in this regard is that I think he connects the dots incorrectly. He agrees that Windows programming was getting too complex and years of cruft  eventually begins to become difficult to manage.  He also thinks the .NET Framework makes developers more productive. So it seems introducing the .NET Framework was the smart thing for Microsoft to do. However he argues that not many people are using it (actually that not many desktop developers are using it) . There are two reasons for this which I know first hand as a developer of a desktop application that runs in the .NET Framework (RSS Bandit)

• The .NET Framework isn't ubiqitous on Windows platforms
• The .NET Framework does not expose enough Windows functionality to build a full fledged Windows application with only managed code.

Both of these issues are why Microsoft is working on WinFX. Again, the elepahant in the living room issue is that it seems that Microsoft's current plans are fix these issues for developing on Longhorn not all supported Windows platforms.

Losing the Backwards Compatibility Religion

Microsoft used to be religious about backwards compatibility, now it no longer is.

Based on my experience as a program Manager for the System.Xml namespace in the .NET Framework I'd say the above statement isn't entirely accurate. Granted, the .NET Framework hasn't been around long enough to acquire a lot of cruft we do already have to be careful about breaking changes. In fact, I'm currently in the process of organizing backing out a change we made in Whidbey to make our W3C XML Schema validation more compliant in a particular case because it broke a number of major XML Web Services on the Web.

However I don't think I've seen anyone go above and beyond to keep bug compatibility in the way Raymond Chen describes in his blog. But then again I don't have insight into what every team working on the .NET

WinFS, Just About Search?

The primary goal of WinFS (making search better)  can be acheived by less intrusive, simpler mechanisms.

I'd actually had a couple of conversations this week with folks related to WinFS, including Mike Deem and Scoble.  We talked about the fact that external perceptions of the whats and whys of WinFS don't really jibe with what's being built. A lot of people think WinFS is about making search better [even a number of Longorn evangelists and marketing folks]. WinFS is really a data storage and data access platform that aims to enable a lot of scenarios, one of which just so happens to be better search. In addition, whether you improve full text search and the indexing service used by the operating system is really orthogonal to WinFS.

The main problem is that what the WinFS designers think WinFS should be, what customers and competitors expect it to be and what has actually been shown to developers in various public Longhorn builds are all different. It makes it hard to talk about what WinFS is or should be when your everyone's mental image of it is slightly different.

Disclaimer: The above statements are my personal opinions and do not reflect the intentions, strategies, plans or opinions of my employer.

A few weeks ago I mentioned I was considering writing a current and future trends in social software, blogging and syndication as part of a Bill Gates "Think Week" paper. Well, it looks like someone beat me to the punch and he already got one as part of the most recent "Think Week". The person who submitted the paper shared BillG's comments which were pretty insightful about some of the issues facing syndication technologies today and some that will loom once their usage becomes more widespread. I have lunch scheduled with the author of the paper so I'll definitely try and exchange some ideas.

In the short term this means I'll probably put any plans of writing such a document on the back burner at least until the end of the summer. Given my current workload at my dayjob (7 hours of meetings tomorrow, didn't get in until about 11PM tonight)  as well as the fact that there is significant work I want to do for the next release of RSS Bandit this probably is for the best anyway.

My submission on Designing Extensible & Version Resilient XML Formats has been accepted to XML 2004. It looks like I'm going to be in Washington D.C. this fall. Currently I'm in the process of writing an article about the topic of my talk which should show up on MSDN and XML.com in the next month or so. Afterwards I plan to submit a revised version of that article as the paper for my talk.

The ongoing conversation between Jeremy Mazner and Jon Udell about the capabilities of WinFS deepen this morning with Jeremy's post Did I misunderstand Udell's argument against WinFS? which was followed up by Jon's post When a journalist blogs. In his post Jon asks

We have standard query languages (XPath, XQuery), and standard ways of writing schemas (XSD, Relax), and applications (Office 2003) that with herculean effort have been adapted to work with these query and schema languages, and free-text search further enhancing all this goodness. Strategically, why not build directly on top of these foundations?

Tactically, why do I want to write code like this:

public class Person
  {
  [XmlAttribute()] public string Title;
  [XmlAttribute()] public string FirstName;
  [XmlAttribute()] public string MiddleName;
  [XmlAttribute()] public string LastName;
  ....

in order to consume data like this?

<People>
  <Person
    DisplayName="Woodgrove Bank"
    IMAddress="Support@woodgrovebank.com"
    UserTile=".\user_tiles\Adventure Works.jpg">
    <EmailAddresses>
        <EmailAddress
            Type="Work"
            Address="mortgage@woodgrovebank.com"/>
        <EmailAddress
            Type="Primary"
            Address="Support@woodgrovebank.com"/>
   </EmailAddresses>

I believe two things to be true. First, we have some great XML-oriented data management technologies. Second, the ambitious goals of WinFS cannot be met solely with those technologies. I'm trying to spell out where the line is being drawn between interop and functionality, and why, and what that will mean for users, developers, and enterprises.

Jon asks several questions and I'll try to answer all the ones I can. The first question about why WinFS doesn't build on XML, XQuery and XSD instead of items, OPath and the WinFS schema language is something that the WinFS folks will have to answer. Of course, Jon could also ask why it doesn't build on RDF, RDQL [or any of the other RDF query languages] and RDF Schema which is a related question that naturally follows from the answer to Jon's question.

The second question is why would one want to program against a Person object when they have a <Person> element. This is question has an easy answer which unfortunately doesn't sit well with me. The fact is that developers prefer programming against objects than they do programming with XML APIs. No XML API in the .NET Framework (XmlReader, XPathNavigator, XmlDocument, etc) comes close to the ease of use of  programming against strongly typed objects in the general case. Addressing this failing [and it is a failing] is directly my responsibility since I'm responsible for core XML APIs in the .NET Framework. Coincidentally, we just had a review with our new general manager yesterday and this same issue came up and he asked what we plan to do about this in future releases. I have some ideas. The main problem with using objects to program against XML is that although objects work well for programming against data-centric XML (rigidly structured tabular data such as an the data in an Excel spreadsheet, a database dump or serialized objects) there is a signficant impedance mismatch when trying to use strongly typed objects to program against document-centric XML (semi-structured data such as a Word document). However the primary scenarios the WinFS folks want to tackle are about rigidly structured data which works fine with using objects as the primary programming model.

Jon says that he is trying to draw the line between interop and functionality. I'm curious as to what he means by interop in this case. The fact that WinFS is based on items, OPath and WinFS schema doesn't mean that WinFS data cannot be exchanged in an interoperable manner (e.g. some form of XML export and import) nor does it mean that non-Microsoft applications cannot interact with WinFS. I should clarify that I have no idea what the WinFS folks consider their primary interop scenarios but I don't think the way WinFS is designed today means it cannot interoperate with other platforms or data models.

I suspect that Jon doesn't really mean interop when says so. I believe he is using the word the same way Java people use it where it really means 'One Language, One Programming Model, One Platform' everywhere instead of being able to communicate between disparate end points. In this case the language is XML and the platform is the XML family of technologies.