We are making strides towards getting an official release of RSS Bandit out in the next week or so, in the mean time early adopters can download the latest version.

The biggest changes are that we have incorporated Oleg's Russian translation which brings our number of supported languages to four (English, German, Russian and Simplified Chinese). There is also a Turkish translation that is half done. The ever diligent Torsten has added the following command line option to RSS Bandit

-c[ulture]:? code>', e.g. '-culture:"ru-RU"'  launches RSS Bandit with Russian UI.

There is also the patch we got from Curt Hagenlocher which adds sort arrows to the columns in the list view when you click them. We also now offer maximum configurability of the MSN Messenger-style pop up windows that tell you if your favorite feeds have been updated. You can configure them on a per feed basis or for all feeds, as well as turn them on or off from the system tray. There have also been minor improvements in memory consumption, about 5%-15%.

Another great development is that the RSS Bandit online documentation is filling up nicely. Kudos to Phil Haack for the great work he is doing on this front. I know new users will love having this information at their fingertips.

As before any comments about the beta version should be brought up on the mailing list or discussion board. Bugs should be filed in the bug database on SourceForge and feature requests go to the feature request database on SourceForge.

According to Eric Gunnerson we now write Static classes in C#

So, for Whidbey, we allow the user to mark a class as static, which means that it's sealed, has no constructor, and the compiler will give you an error if you write an instance method.

Rumor has it that the 1.0 frameworks shipped with an instance method on a static class.

This would be nice to have in the language. I know it would have helped us catch the fact that the System.Xml.XmlConvert class which only has static methods was shipped with a [useless] default constructor.

A recent post by Brad Abrams on DateTime, Serialization and TimeZones highlights one of the problems with the the System.Datetime structure. The best way to illustrate his problem is with a code fragment and the output from the code

    DateTime now = DateTime.Now;
   
    Console.WriteLine(now);
    Console.WriteLine(now.ToUniversalTime());

    Console.WriteLine(XmlConvert.ToString(now));
    Console.WriteLine(XmlConvert.ToString(now.ToUniversalTime()));

which results in the following output

4/14/2004 9:29:31 AM
4/14/2004 4:29:31 PM
2004-04-14T09:29:31.9531250-07:00
2004-04-14T16:29:31.9531250-07:00

which at first seems right until you consider that all the values should reflect the same instant in time but do not. The problem is that the DateTime structure does not store time zone information which causes all sorts of problems when trying to transmit date or time values across the network or persist them. I've had to deal with this because I'm responsible for the System.Xml.XmlConvert class and have been working with folks that are responsible for XML Serialization, the DataSet and the CLR team as to how best to work around this problem. As Brad Abrams mentions in his blog post 

You can mark a DateTime instance as Local, UTC or Unspecified, and Unspecified means that it should not be serialized with a time zone. Unfortunately it won't magically take effect because it would break compatibility. But there will be ways to opt-in to this behavior for DataSet, XML Serialization and XML Convert.

 so there won't be time zone information added to the type but at the very least it should be possible to get my code fragment above to emit equivalent times in Whidbey. So time zone information still won't be supported but you can always normalize to UTC and have this preserved correctly instead of what happens now.

This is what has been proposed and I'm in the process of working out exactly how this should work for XmlConvert. We will most likely add overloads to the ToString method that takes a DateTime that allows people to control whether they want the backwards compatible (but incorrect) v1.0 behavior or the correct behavior when outputing a UTC date.

I just noticed a post on Mark Pilgrim's blog entitled Hot RSS where he writes

I would like to applaud CNET for their courageous invention of a completely new and incompatible version of RSS. They call it dlhottitles, but I think it deserves to be named something sexy, like “Hot RSS”. Here’s a live sample (static mirror). Some people might say that CNET was ripping up the pavement by inventing their own incompatible syndication format instead of re-using one of the myriad of existing incompatible syndication formats. Some people might get a little hot and bothered about the fact that CNET is featuring it prominently on a page entitled “Simply RSS”, complete with the requisite orange XML button that shows that this is truly the product of a clued-in syndication producer. But I say: the more RSS the merrier!

I am completely perplexed by this move by C|Net, I can only hope it's a belated April Fool's joke. I wanted to join in the fun and add support for the format to RSS Bandit but my my problems from yesterday have left me without a working install of Visual Studio.

Viva la Hot RSS.

Yesterday, I decide to work from home since it's a nice day and I have a bunch of documentation to write. Halfway through the day I get a number of emails that require me to connect to work via the VPN. In trying to do soand spending some time with folks from the MSFT HelpDesk I managed to hose my Windows box and require a reinstall.

So I spent half of yesterday getting my machine back up to speed and I'm still not done. I just figured out the IIS permission issues and got my blog back online. I still need to figure out how to get both versions of Visual Studio back online. Then there's the fact I never got the stuff I needed to get done at work or finished writing the documentation I was planning to in the first place.

Mondays really suck.

Rory Blyth recently blogged that he was invited to attend the 2004 Microsoft MVP Summit without being an MVP. This has caused some outcry from some members of the .NET programming community. I've seen some complaints from Roy Osherove who wrote Non MVPs at the MVP summit - looks bad, smells bad and Ted Neward who's written MVP: What's in a name? that inviting people who aren't MVPs to the MVP Summit diminishes the value of being an MVP. As the community lead for my team I tend to share their sentiments. I'll reserve comment about this particular incident since all the details are not available.

I did feel drawn to post because Ted Neward wrote 

 Meanwhile, for those who've asked over blogs and mailing lists, becoming an MVP is not a mystical or mysterious process, but it is somewhat subjective and arbitrary: as I understand it, in essence, when it comes time to select new MVPs, existing MVPs nominate names they've seen active within the community (writing books, speaking, blogging, activity on the newsgroups and various community portals, and so on), and from there the rest of the MVPs in that "group" sort of hash out who's worthy and who's not.

I don't know about other products and technologies but that isn't how it's worked for the case of the “Visual Developer - XML” category. Various internal and external folks can nominate MVPs through myself or two people from the MVP program, Ben Miller is one of the other people, and we actually enter the nomination information. Then three of us vote on who should be an MVP based on what we know first hand or second hand about the individual. I'm sure some teams encourage the MVPs to be directly involved in the process but that doesn't mean that is the rule for how things work with regards to MVP nominations. Also I'm sure product teams and the MVP program have veto power on whoever is awarded as an MVP even for folks nominated by other MVPs.

I was reading Mark Pilgrim's ariticle entitled The Vanishing Image: XHTML 2 Migration Issues and stumbled on the following comment

You (the author of this article) have a valid point when you say people will want to upgrade to XHTML 2, against the HTML Working Group's expectation/intention. From the tone of this article, one would assume you find this a bad development; I however disagree: I think people should update their website to comply with the latest standards. Authors will have to rewrite their pages into XHTML 2.0, but, with server-side scripting and CSS in mind, this should be a not so very difficult task.

I'm always surprised when I see web design geeks advocating the latest and greatest standards with no indication of what the real benefits are besides the fact that they can place meaningless badges such as   on their website. Technology standards are a means to an end not an end in themselves. The purpose of having well specified technology standards is to guarantee interoperability between software and hardware produced by different vendors. In the case of XHTML, many who have looked at the situation objectively have failed to find any reasons why one should migrate to XHTML 1.0 from HTML 4.01. Arguing that people should migrate to a version of XHTML that isn't even backwards compatible with HTML seems highly illogical since it runs counter to the entire point of standardizing on a markup language in the first place, interoperability. 

Many people designing XML formats whether for application-specific configuration files, website syndication formats or new markup languages have to face the problem of how to design their formats to be extensible and yet be resilient to changes due to changes to versions of the format. One thing I have noticed in talking to various teams at Microsoft and some of our customers is that many people think about extensibility of formats and confuse that for being the same as the versioing problem.  I have written previously On Versioning XML Vocabularies in which I stated

At this point I'd like to note that this a versioning problem which is a special instance of the extensibility problem. The extensibility problem is how does one describe an XML vocabulary in a way that allows producers to add elements and attributes to the core vocabulary without causing problems for consumers that may not know about them. The versioning  problem is specific to when the added elements and attributes actually are from a subsequent version of the vocabulary (i.e. a version 2.0 server talking to a version 1.0 client).

The problem with the above paragraph is that it it focuses on a narrow aspect of the versioning problem. A versioning policy should not only be concerned with when new elements and attributes are added to the format but also when existing ones are changed or even removed.

The temptation to think about versioning as a variation of the extensibility problem is due to the fact that the focus of the XML family of technologies has been about extensibility. As I wrote in my previous posting

One of the primary benefits of using XML for building data interchange formats is that the APIs and technologies for processing XML are quite resistant to additions to vocabularies. If I write an application which loads RSS feeds looking for item elements then processes their link and title elements using any one of the various technologies and APIs for processing XML such as SAX, the DOM or XSLT it is quite straightforward to build an application that processes said elements which is resistant to changes in the RSS spec or extensions to the RSS spec as the link and title elements always appear in a feed.  

Similarly XML schema languages such as W3C XML Schema have a number of features that promote extensibility such as wildcards, substitution groups and xsi:type but few if any that target the versioning problem. I've written about a number of techniques for adding extensibility to XML formats using W3C XML Schema in my article W3C XML Schema Design Patterns: Dealing With Change but none so far on approaches to versioning in combination with your favorite XML schema language.

There are a number of things that could change about the constructs in a data transfer format including

1. New concepts are added (e.g. new elements or attributes added to format or new values for enumerations)

2. Existing concepts are changed (e.g. existing elements & attributes should be interpreted differently, added elements or attributes alter semantics of their parent/owning element)

3. Existing concepts are deprecated (e.g. existing elements & attributes should now issue warning when consumed by an application)

4. Existing concepts are removed (e.g. existing elements & attributes should no longer work when consumed by an application)

How all four of the above changes between versions of the XML format are handled should be considered when designing the format. Below are sample solutions for each of the aformentioned changes

1. New concepts are added: In some cases the new concepts are completely alien to those in the existing format. For example, the second version of XQueryX will most likely have to deal with the additions of data update commands such as insert or delete while the existing format only has query constructs. In such cases it is most prudent to eschew backwards compatibility by either changing the version number or namespace of XML format. On the other hand, if the new additions are optional or ignorable and the format has extensibility rules for items from a different namespace than that of the format itself then the new additions (elements and attributes) can be placed in a different namespace from that of the format. In more complex cases, it may be likely that there are some additions that cannot be ignored by older processors while others can. In such cases, serious consideration should be made for adding a concept similar to the mustUnderstand attribute in SOAP 1.1 where one can indicate which additions to the format are backwards compatible and which ones are not.

   In the case of new possible values being added to an enumeration (e.g. a color attribute that had the option of being "red" or "blue" in version 1.0 of the format has "green" added as a possible value in future version of the format) the specification for the format needs to determine what the behavior of older processors should be when they see values they do not understand.

2. Existing concepts are changed: In certain cases the interpretation of an element or attribute may be changed across versions of a vocabulary. For example, the current working draft of XSLT 2.0 has a list of incompatibilities between it and XSLT 1.0 when the same elements and attributes are used in a stylesheet. In such cases it is most prudent to change the major version number of the format if one exists or change the namespace of the format otherwise. This means the format will not be backwards compatible.

3. Existing concepts are deprecated: Sometimes as a format evolves, one realizes that some concepts need to be reworked and replaced by improved implementations of these concepts. An example of this is the deprecation of the requiredRuntime element in favor of the supportedRuntime element in .NET Framework application configuration files. Format designers need to consider how to make such changes work in a backwards compatible manner. In the case of .NET Framework configuration files, both elements are used for applications targetting version 1.0 of the .NET Framework since the former is understood by the configuration engine while the latter is ignored.

4. Existing concepts are removed: Constructs may sometimes be removed from formats because they prove to be inappropriate or insecure. For example, the most recent draft of XHTML 2.0 removes familiar elements like img and br (descriptions of the backwards incompatible changes in XHTML 2.0 from XHTML 1.1 are available in the following articles by Mark Pilgrim, All That We Can Leave Behind and The Vanishing Image: XHTML 2 Migration Issues). This approach removes forwards compatibility and in such cases it is most prudent to either change the version number or namespace of the XML format.

This blog post just scratches the surface of what can be written about the various concerns when designing XML formats to be version resilient. There are a couple of issues as to how best to represent such changes in an XML schema and if one should even bother trying in certain cases. I'll endeavor to put together an artricle about this on MSDN in the next month or two.

Matevz Gacnik points out Serious bug in System.Xml.XmlValidatingReader, he writes

The schema spec and especially RFC 2396 state that xs:anyURI instance can be empty, but System.Xml.XmlValidatingReader keeps failing on such an instance.

To reproduce the error use the following schema:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="AnyURI" type="xs:anyURI">
  </xs:element>
</xs:schema>

And this instance document:

<?xml version="1.0" encoding="UTF-8"?>
<AnyURI/>

There is currently no workaround for .NET FX 1.0/1.1. Actually Whidbey is the only patch that fixes this. :)

The schema validation engine in the .NET Framework uses the System.Uri class for parsing URIs. This class doesn't consider an empty string to be a valid URI which is why our schema validation considers the above instance to be invalid according to its schema. However it isn't clear cut in the specs whether this is valid or not at least not without a bunch of sleuthing. As Micheal Kay (XSLT working group member) and C.M. Speilberg-McQueen (chairman of the XML Schema working group) wrote on XML-DEV

To: Michael Kay <michael.h.kay@ntlworld.com>
Subject: RE: [xml-dev] Can anyURI be empty?
From: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
Date: 07 Apr 2004 10:49:51 -0600
Cc: xml-dev@lists.xml.org

On Wed, 2004-04-07 at 03:47, Michael Kay wrote:
> > If it couldn't, it would be wrong. An empty string is a valid URI.
>
> On this, like so many other things, RFC 2396 is a total disaster. An empty
> string is not valid according to the BNF syntax, but the RFC gives detailed
> semantics for what it means (detailed semantics, though very imprecise
> semantics).
>
> And the schema REC doesn't help. It has the famous note saying that the
> definition places "only very modest obligations" on an implementation, and
> it doesn't say what those obligations are.

Yes.  This is a direct result of our realization that
we have as much trouble understanding RFC 2396 as anyone
else.  The anyURI type imposes the obligations of
RFC 2396, whatever those are.  Any attempt to paraphrase
them on our part would lead, I fear, to an unsatisfactory
result: either we would make some mistake (like believing
that since the BNF does not accept the empty string,
it must not be legal) or we would make no mistakes.  In
the one case, we'd be misleading our readers, and in
either case, we'd find ourselves mired in a never-ending
effort to prove that our paraphrase was, or was not,
correct. 

RFC 2396 is one of the fundamental specifications of the World Wide Web yet it is vague and contradictory in a number of key places. Those of us implementing standards often have to go on gut feel or try and track the spec authors whenever we bump across issues like this but sometimes we miss them.

All I can do is apologize to people like Matevz Gacnik who have to bear the brunt of the lack of interoperability caused by vaguely written specifications implemented on our platform and for the fact that a fix for this problem won't be available until Whidbey.