November 11, 2004
@ 03:54 PM

Yesterday I literally stopped being the face of XML at Microsoft. From now on if you go to http://www.microsoft.com/xml or http://msdn.microsoft.com/xml you won't see my work blog or my picture welcoming you to the XML Developer Center at MSDN. It's a particularly bittersweet experience. I fought with MSDN for about a year and a half to get that site launched and for a while I felt that it was my baby. The new owner of the site, Irwin, is a great guy and I'm sure he'll do excellent things with it.

Speaking of transitions, I'm still trying to fit in at MSN. It's interesting going from being extremely knowledgeable about all the technologies I'm responsible for to returning blank stares when asked about some aspect of a spec I now own. Hopefully I'll have some downtime at next week's XML 2004 conference to bone up on the various specs about our backend infrastructure so I don't seem so clueless at the next feature costing meeting. :)

So far the new job's been awesome. Great people and the features I'm working on are killer. Best of all I not only get to deliver features for MSN Spaces but also Hotmail, MSN Messenger and even MyMSN. Of course, this means I attend lots and lots of cross-team meetings. Yay, fun...


 

Categories: Life in the B0rg Cube | MSN

November 10, 2004
@ 06:00 AM

A comment in Slashdot pointed out to me that it's been a day full of good news. On this day we find out that

  1. Halo 2 Released
  2. Firefox 1.0 Released
  3. U.S. Attorney General John Ashcroft Resigns

The last one is spectacularly good news [unless he is nominated as a Supreme Court Justice].


 

I saw The Incredibles this weekend and it was great. The animation was amazing, the story top notch and it had the right ratio of action to humor. This is probably one of the best super hero movies I've ever seen.

Rating: ***** out of *****

 


 

Categories: Movie Review

November 9, 2004
@ 01:28 PM

A recent post entitled Finally, a Use for Atom by Charles Miller got me thinking about the usefulness or lack thereof of the IETF Atom effort. It seems I wasn't the only one who started thinking this given a mail thread started by Tim Bray on the atom-syntax list entitled Posted PaceDeclareVictoryOnFormat where he writes

To: Atom WG <atom-syntax@xxxxxxx>
Subject: Posted PaceDeclareVictoryOnFormat
From: Tim Bray <Tim.Bray@xxxxxxx>
Date: Mon, 08 Nov 2004 14:13:17 -0800

See http://www.intertwingly.net/wiki/pie/PaceDeclareVictoryOnFormat

The world can use Atom, sooner rather than later. The return-on-investment of further WG time invested in polishing something that's already pretty good is starting to be very unattractive. Particularly when the Protocol draft seriously needs work and progress.

Note that this has not been formally placed at the front of the queue yet. -Tim

I posted some comments to the thread that reflect the same opinions from my post Mr. Safe's Guide to the RSS vs. ATOM debate, the relationship between the Atom syndication format and RSS is the same as that of XHTML and HTML; geeks will like it but there's no real concrete reason to use it over the old stuff that already works pretty well for the most part.

However I also reiterated that I think the Atom API is a worthwhile addition to the world of blogging technologies. I listed the problems with the current crop of blog posting APIs such as the Blogger API and MetaWeblog API in my post What's Wrong with the MetaWeblog API? from a year and a half ago

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).

Strongly Coupled To XML-RPC: RSS and Joe Gregorio's CommentAPI have shown that one can build applications that retrieve and send XML documents from client to server directly using HTTP GET and POST instead of going through an added layer of indirection by using exlicit RPC mechanisms.
...
I also believe that there should be the API should not just be tied to XML-RPC but should have interfaces that utilize the XML Web Services family of technologies like SOAP and WSDL not just XML-RPC. There are many products and toolkits that support SOAP/WSDL/etc plus more are being built every day. It makes little sense to me that almost everywhere else in the software industry people are either exchanging XML documents using RESTian principles (i.e. HTTP GET and POST) or the XML Web Services family of technologies but when it comes to web content related technologies there is this anachronism where an arbitrarily different methodology is used.

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.

As time has passed some of my opinions on this matter have mellowed. Security is a big problem and one I don't think can be ignored. The fact that existing APIs depend on XML-RPC instead of more accepted industry practices such as using RESTian principles or SOAP+WSDL isn't that great but it isn't that big a deal. The issue of limited functionality is probably something that has to be lived with since for the API to be widely adopted it has to support a lowest common denominator of features. As long as the API can be extended then the fact that there isn't some functionality in the core isn't that bad.

So for me, the high order bit is security. I can see at least two ways to solve this problem listed in order of least disruptive to most disruptive

  1. Blog editing tools and blog vendors moving towards using XML-RPC over HTTPS/SSL or at least use digest HTTP authentication instead of HTTP.
  2. Blog editing tools and blog vendors moving towards using the Atom API over HTTPS/SSL or at least use digest HTTP authentication instead of HTTP.

A number of blog hosting services such as Blogger/Google and SixApart have moved towards doing (2) above. However it is unclear to me how much this has been embraced by builders of popular blog editing tools such as BlogJet and w::bloggar. Looking at the list of Atom Enabled client software I only see aggregators listed but not blog editing tools.

So I was curious, are there any major blog editing tools that support the Atom API? If not, do these tools support using the Blogger/MetaWeblog API over HTTPS/SSL? If not, is there any interest in doing the former or the latter any time soon?


 

There was a recent posting on the RSS Bandit bug forum entitled Weblog comments do not appear in listview where the author wrote

I use Wordpress to generate my site feed (http://www.chaoszone.org/index.xml). Wordpress supports wfw:commentRSS, but RSS Bandit is unable to show comments for posts in this feed inside the listview (the way it does for Dare's and other MSDN weblogs). Instead, I have to click through to go to the comments page.

I've since tweaked the basic Wordpress RSS2 generator routine to include slash:comments -- a temp feed is available here: http://www.chaoszone.org/rss-with-slashcomments.xml

Since the element in question is supported by RSS Bandit and I can view comments just fine in any dasBlog or Community Server::Blogs (formerly .TEXT) weblog I assumed this was a bug in WordPress. Eventually I tracked down the problem to an issue of capitalization.

The element in question is called wfw:commentRss in Chris Sells' original specification but incorrectly transcribed as wfw:commentRSS in Joe Gregorio's list of the wfw namespace elements. Since it looks like at least one blog tool uses the latter capitalization the next version of RSS Bandit will support both versions of the element. This means that comments to blog posts on WordPress-based blogs will now show up in the next version of RSS Bandit.


 

Categories: RSS Bandit

November 4, 2004
@ 06:10 PM

Many times when implementing XML specifications I've come across I've come up against feature that just seem infeasible or impractical to implement. However none of them have given me nightmares as they have my friend Mike Vernal, a program manager on the Indigo team at Microsoft. In his post could you stop the noise, i'm trying to get some rest ... he talks about spending nights tossing and turning having nightmares about how the SOAP mustUnderstand header attribute should be processed. In Mike's post More SOAP Sleepness he mentions having sleepless nights worrying about the behavior of SOAP intermediaries as described in Section 2.7: Relaying SOAP Messages.

This isn't to say I didn't have sleepless nights over implementing XML specifications when I worked on the XML team at Microsoft. One of the issues that consumed a lot more of my time than is reasonable is explained in Derek Denny-Brown's post Loving and Hating XML Namespaces 

Namespaces and your XML store
For example, load this document into your favorite XML store API (DOM/XmlBeans/etc)
 <book title='Loving and Hating XML Namespaces'>
   <author>Derek Denny-Brown</author>
 </book>
Then add the attribute named "xmlns" with value "http://book" to the <book> element. What should happen? Should that change the namespaces of the <book> and <author> elements? Then what happens if someone adds the element <ISBN> (with no namespace) under <book>? Should the new element automatically acquire the namespace "http://book", or should the fact that you added it with no namespace mean that it preserves it's association with the empty namespace?

In MSXML, we tried to completely disallow editing of namespace declarations, and mostly succeeded. There was one case, which I missed, and we have never been able to fix it because so many people found it an exploited it. The W3C's XML DOM spec basically says that element/attribute namespaces are assigned when the nodes are created, and never change, but is not clear about what happens when a namespace declaration is edited.

Then there is the problem of edits that introduce elements in a namespace that does not have an existing namespace declaration:
<a xmlns:p="http://p/">
  <b>
    ...
      <c p:x="foo"/>
    ...
  </b>
</a>
If you add attribute "p:z" in namespace "bar" to element <b>, what should happen to the p:x attribute on <c>? Should the implementations scan the entire content of <b> just in case there is a reference to prefix "p"?

Or what about conflicts? Add attribute "p:z" in namespace "bar" to the below sample... what should happen?
<a xmlns:p="http://p/" p:a="foo"/>

This problem really annoyed me while I was the PM for the System.Xml.XmlDocument class and the short-lived System.Xml.XPath.XPathDocument2. In the former, I found out that once you started adding, modifying and deleting namespace declarations the results would most likely be counter-intuitive and just plain wrong. Of course, the original W3C DOM spec existed before XML namespaces and trying to merge them in after the fact was probably a bad idea. With the latter class, it seemed the best we could do was try and prevent editing namespace nodes as much as possible. This is the track we decided to follow with the newly editable System.Xml.XPath.XPathNavigator class in the .NET Framework.

This isn't the most sleep depriving issue I had to deal with when trying to reflect the decisions in various XML specifications in .NET Framework APIs. Unsurprisingly, the spec that caused the most debate amongst our team when trying to figure out how to implement its features over an XML store was the W3C XML Schema Recommendation part 1: Structures. The specific area was the section on contributions to the Post Schema Validation Infoset and the specific infoset contribution which caused so much consternation was the validity property.

After schema validation an XML element or attribute should have additional metadata added to it related to validation such as it's type, its default value specified in the schema if any and whether it is valid or not according to its type. Although the validity property is trivial to implement on a read-only API such as the System.Xml.XmlReader class, it was unclear what would be the right way to expose this in other representations of XML data such as the System.Xml.XmlDocument class. The basic problem is "What happens to the validity propety of the element or attribute those of all its ancestors once the node is updated?". Once I change the value of an age element which is typed as an integer from 17 to seventeen what should happen. Should the DOM test every edit to make sure it is valid for that type then reject it otherwise? Should the edit be allowed but the validity property of the element and all its ancestors be changed? What if there is a name element with required first and last elements and the user wants to delete the first element and replace it with a different one? How would that be reflected with regards to the validity property of the name element?

None of the answers to the question we came up with satisfactory. In the end, we were stuck between a rock and a hard place so we made the compromise choice. I believe we debated this issue every other month for about a year.


 

Categories: XML

November 3, 2004
@ 05:45 PM

According to the CTV article Election voter turnout highest in 30 years 

About 120 million people cast ballots, or just under 60 percent of eligible voters — the highest percentage turnout since 1968, said Curtis Gans, director of the nonpartisan Committee for the Study of the American Electorate.

In the 2000 election, when Republican George W. Bush squeaked out a win over Democrat Al Gore, slightly more than 54 per cent of eligible voters, or about 105.4 million, voted.

Gans said the modern record for voter turnout was 1960, when 65 per cent of those eligible cast ballots to back Democrat John Kennedy over Republican Richard Nixon.

More detailed figures were expected later Wednesday.

Still, despite the high turnout, 2004 did not prove to be a breakout year for young voters.

Exit polls indicated that fewer than one in 10 voters who came out on Tuesday were 18 to 24. That's about the same proportion of the electorate as in 2000.

It looks like P. Diddy's Vote Or Die campaign didn't get the MTV demographic out after all. However I was quite amused to see him as one of the election pundits on MSNBC last night.


 

Yesterday I found out that a shortage of styrofoam cups in the kitchen that we experienced in our building was actually occuring all over the Redmond campus. Some of us joked last night that this was the latest in the string of penny wise, pound foolish cost cuttings in the same vein as only having office supplies on one floor of the building.

This morning I realized that moving all of a particular resource to one floor to "cut costs" was actually an example used in The Dilbert Principle in a section entitled Companies That Turn On Themselves.

I wonder what other Dilbert-esque cost cutting moves folks out there have experienced? Post your favorites in the comments to this post.


 

Categories: Life in the B0rg Cube

I've been watching the hype about podcasting with some wariness but it looks like it is here to stay. I just noticed that Greg Reinacker (NewsGator) and Nick Bradbury (FeedDemon) have announced that they will have better support for RSS 2.0 enclosures and thus podcasting. This weekend I also started the roots of getting podcasting support into RSS Bandit, Torsten will likely finish this work once he is done with the GUI for NNTP newsgroup support.

Speaking of podcasting and RSS 2.0 enclosures, I agree 100% with Joshua Allen's points in his post, History of Podcasting. He wrote

Dave Winer doesn't want to end up like Eric Bina, written out of the history of a creation he helped usher into reality.  Adam steps up to make sure Dave gets credit.  This time, there is less reason to worry.  First, the WWW (which Eric helped enable) is now an independent and democratic public record which can triangulate the major media.  And blogs, which Dave helped enable, are one source of that public record.  The public record shows that Dave was planning “Radio” via RSS for a very long time.  Dave has talked about these ideas for a long time, but I have to admit that I wasn't quite prepared for how fast it would actually happen.  I believe credit goes to Adam for such a fast and effective bootstrap, but it also proves that all of the work on RSS laid a good foundation for quick incremental innovation.  

I also think that one of the major success factors was that the nattering nabobs ignored podcasting and dismissed it until it was too late to inject their stop energy.  Many of the nabobs were so convinced of their own stories about “RSS is broken”,  that it never occured to them that something like podcasting could be successful.  They were so busy trying to reinvent RSS that they ignored an idea that Dave has been giving away for free for years. 

There's a lot of innovation and interesting end user applications that can be built on RSS today. However many XML syndication geeks are prideful and would rather reinvent the wheel than use existing technology to solve real world problems.


 

November 1, 2004
@ 03:02 PM

Yesterday I found out my car had been broken into the previous night. I can't get over the fact that I had my car parked on the street at Pioneer Square until almost 2AM on Sunday but it gets broken into in the supposely secure underground parking garage of my apartment complex.

The wave of emotions washing over me this past 12 hours has been interesting. The ones that have stuck so far are the sense of violation and the anger. I've learned the hard way to never leave anything important in my car thinking that because its in the trunk it'll be "safe" .

Bah, I need to get ready for work.

 


 

Categories: Ramblings