The final beta version of RSS Bandit before the next release is available, you can download the latest version.

The major change in this version is that you can now synchronize RSS Bandit using WebDAV, FTP or a file share. We transfer the data in ZIP file. If you select WebDAV, FTP or file share we'll synchronize your search folders, flagged items, replied items, subscribed feeds and read/unread message state. All of these will be transferred as a ZIP file. You can also select the dasBlog option which will upload/download your feedlist as an OPML file from your weblog. The latter is functionality that has always existed which hasn't being modified to perform synchronization. 

I'll spend the weekend ironing out bugs in this feature and trying to fix some areas that cause a lack of responsiveness in the GUI. We should have a release on Monday or Tuesday at the latest.

 

I've been reading quite a bit about various opinions on standards in the software industry. The first piece I read about this was the C|Net article  You call that a standard? where Robert Glushko said

Q: Why have so many standards emerged for electronic commerce?
A: One of the issues here is what a standard is. That is one of the most abused words in the language and people like you (in the media) do not help by calling things standard that are not standards. Very few things are really standard. Standards come out of standards organizations, and there are very few of those in the world.

There is ANSI (American National Standards Institute), there is ISO (International Organization for Standardization), the United Nations. Things like OASIS and the W3C (World Wide Web Consortium) and WS-I (Web Services Interoperability Organization) are not standards organizations. They create specifications that occasionally have some amount of consensus. But it is the marketing term to call things standard these days.

I tend to agree that a lot of things the media and software industry pundits call “standards” are really specifications not standards. However I'd even claim that simply calling something a standard because some particular organization produced it doesn't really jibe with reality. There has been lengthy discussion about this C|Net article on XML-DEV and in one of the posts I wrote

The word "standard' when it comes to software and computer technology is usually meaningless. Is something standard if it produced by a standards body but has no conformance tests (e.g. SQL)? What if it has conformance testing requirements but is owned by a single entity (e.g. Java)? What if it is just widely supported with no formal body behind it (e.g. RSS)?
 
Whenever I hear someone say standard it's as meaningless to me as when I hear the acronym 'SOA', it means whatever the speaker wants it to mean.

Every one of the technologies mentioned in my post(s) on XML-DEV (SQL, Java, RSS, Flash) can be considered standards by developers and their customers for some definition of the word 'standard'. In particular, I want to sieze on Glushko's claim that standards are things produced by standards bodies with the example of ANSI (American National Standards Institute) and the “SQL standard”. Coincidentally I recently read an article entitled Is SQL a Real Standard Anymore? written by Michael Gorman who has been the Secretary of the ANSI (American National Standards Institute) NCITS (National Committee on Information Technology Standards) H2 Technical Committee on Database for over 23 years. In the article he begins

What Makes a Standard a Standard?

Simple. Not implementation, but conformance. And, conformance is “known” only after conformance testing. Then and only then can users know with any degree of certainty that a vendor’s product conforms to a standard.
...
But, from the late 1980s through 1996 there was conformance testing. This was accomplished by the United States Government Department of Commerce’s National Institute of Standards and Technology (NIST). NIST conducted the tests in support of public law that was originally known as the"Brooks Act," and later under other laws that were passed in the 1990s. The force behind the testing was that no Federal agency was able to buy a DBMS unless it passed conformance tests. Conformance meant the possibility of sales.
...
The benefits derived from the NIST conformance tests were well documented. A NIST commissioned study showed that there were about $35 million in savings from a program that only cost about $600 thousand. But, in 1996, NIST started to dismantle its data management standards program. The publically stated reason was"costs." Obviously, that wasn’t true.
...
In May of 1996, I wrote an article for the Outlook section of the Washington Post. It was unpublished as it was considered too technical. The key parts of the article were:

"Because of NIST’s FY-97 and beyond plans, SQL’s conformance tests and certifications, that is, those beyond the SQL shell will be left to the ANSI/SQL vendors. They however have no motivation whatsoever to perform full and complete testing nor self policing. Only the largest buyer has that motivation, and in the case of ANSI/SQL the largest buyer is the United States Government.
...
"Simply put, without robust test development and conformance testing by NIST, DBMS will return to the days of vendor specific, conflicting features and facilities that will lock Federal agencies into one vendor, or make DBMS frightfully expensive acquire, use, and dislodge.”

This definitely hits the nail on the head. Standards are a means to an end and in this case the goal of standards is to prevent vendor lock-in. That's it, plain and simple. The rest of Michael  Gorman's article goes on to elaborate how the things he predicted in his 1996 article have come pass and why SQL isn't much of a standard anymore since vendors basically pay lip service to it and have no motivation to take it with seriousness. Going back to Glushko's article on C|Net, SQL is a standard since it is produced by a standards body yet here we have the secretary of the committee saying that it isn't. Who are we to believe?

From my point of view, almost everything that is called a 'standard' by the technology press and pundits is really just a specification. The fact that W3C/ISO/ANSI/OASIS/WS-I/IETF/etc produced a specification doesn't make it a 'standard' by any real definition of the word except for one that exists in the minds of technology pundits. Every once in a while someone at Microsoft asks me “Is RSS a standard?“ and I always ask “What Does That Mean?“ because as shown by the articles linked above it is an ambiguous question. People ask the question for various reasons; they want to know about the quality of the specification, the openness of the process for modifying or extending the specification, where to seek clarifications, or whether the technology is controlled by a single vendor. All of these are valid questions but few [if any] of them are answered by the question “Is <technology foo> a standard“.

 

Breaking up with someone is another way of saying "I'd rather be alone than be with you".

:(

 

A few weeks ago Robert Scoble and Charles Torre came by my office and interviewed me for about an hour. The interview was impromptu and I rambled about all things XML at Microsoft. below are clips of the interview that have made it to Channel 9

1. What is the biggest misperception of XML?

2. What is the best place to learn about XML?

3. Is Microsoft supporting XML standards?

4. Where is Microsoft going with RSS/syndication?

5. What would you pitch Bill Gates on?

I was unprepared for the questions and tended to ramble when answering some of the questions but the answers were more honest and off the cuff.

 

In response to a recent post by Joel Spolsky, Robert Scoble asks if Does Joel believe that blogging is a waste of time?. I found Joel's response in the comments to Robert's post interesting. Joel writes

For every brilliant, useful post by Raymond Chen, there are ten "So, I think I'll try this blogging thing" posts.

What's unusual is for a small company to manage to force a large company to react, and that's what Dave effectively did. It took a lot of work to get the train rolling but now Microsoft is devoting enormous resources to blogging. Even if there are only 400 bloggers, and lets say that each blogger only spends 10% of their time blogging, that's the equivalent of 40 full time employees soaked up... about 10 times the staff of UserLand. If Microsoft gets to the point of 100% blogging which I'm sure is a reasonable goal, we're talking about the equivalent of 5000 employees getting paid to post about what they had for breakfast. That's how many employees Microsoft had TOTAL when I worked there. Dave Winer's idea could conceivably do more to soak up employee resources at Microsoft than Linus Torvald's idea, and that's why it's brilliant. In fact it could even surpass Wes Cherry's idea in sheer time-soaking-up ability. That would be something.

I find Joel's perspective interesting. First of all, I seriously doubt that Microsoft could ever get to the point where 100% of its employees were blogging. Secondly, he makes it seem that blogging doesn't provide value to Microsoft and it is a mere waste of time. This is very, very far from the truth. Besides the abstract benefits such as the fact that it “humanizes” Microsoft to developers there are many practical benefits which we provide to our customers.

Up until blogging, the only channels for getting technical information to our customers were press releases, articles on MSDN or Knowledge Base articles. That is a fairly high barrier to getting information that people working with Microsoft software need to get their jobs done. It isn't like this information doesn't exist. Daily there are hundreds of emails full of information about the inner workings of some component, the roadmap for some technology or the work around flying around the internal aliases at Microsoft that our customers never get to see but would be amazingly useful to them. Take Raymond Chen's blog as an example of this. About 3 years ago when I interned at Microsoft I stumbled on his internal web page that contained all sorts of interesting, useful and technical anecdotes about the history of Windows programming. Up until blogging, useful information such as What order do programs in the startup group execute?, Why are HANDLE return values so inconsistent? , or Why can't the system hibernate just one process? simply languished as information that was only privy to the folks who happened to be on the right email distribution lists at Microsoft or stumbled on the right internal website. Raymond's blog isn't the only one like this, just today I've seen Don Box post about the roadmap for .NET Remoting, Omar Shahine has a post on the issues with building .NET Framework components as addins to Outlook and Philo Janus on implementing context sensitive Help in InfoPath.

Would our customers have access to this wealth of information if we restricted ourselves to traditional channels of communication (press releases, white papers, KB articles, etc)? I don't think so. I do agree that like most things there are high quality blogs from Microsoft employees and others that aren't as useful. But that's life, 99% of everything is crap.

 

It seems April is the month of custom implementations of the XmlReader. The first entry was Daniel Cazzulino's XPathNavigatorReader. As Daniel writes

There are many reasons why developers don't use the XPathDocument and XPathNavigator APIs and resort to XmlDocument instead... XPathNavigator is a far superior way of accessing and querying data because it offers built-in support for XPath querying independently of the store, which automatically gain the feature and more importantly, because it abstracts the underlying store

There are some problems with the XPathNavigator as implemented in the .NET Framework in v1.0 and v1.1. For the most part the APIs in the .NET Framework that work with XML mostly operate on instances of XmlReader or to a lesser extent XmlNode not  XPathNavigator. Also there are some basic features one would expect from an XML API such as the ability to get the XML as a string which don't exist on the class. Daniel solves a number of these problems by implementing the XPathNavigatorReader which is a subclass of XmlTextReader implemented of over an XPathNavigator. This way you can pass an XPathNavigator to APIs expecting an XmlReader or XmlTextReader and get some user friendly functions like ReadInnerXml().

The second custom XmlReader I've seen this month is Oleg Tkachenko's XIncludingReader which is featured as part of his article on the MSDN entitled Combining XML documents with XInclude which provides a brief overview of XInclude and shows how to use the XIncludingReader which implements the XInclude 1.0 Last Call Working Draft from November 10, 2003. From the article

The key class within XInclude.NET is the XIncludingReader, found in the GotDotNet.XInclude namespace. The primary design goal was to build pluggable, streaming pipeline for XML processing. To meet that goal, XIncludingReader is implemented as an XmlReader, which can be wrapped around another XmlReader. This architecture allows easy plugging of XInclude processing layer into a variety of applications without any major modifications.

XML Inclusion process is orthogonal to XML parsing, validation, or transformation. That effectively means it's up to you when to allow XML Inclusion happen: after parsing, but before validation; or after validation, but before transformation, or even after transformation

The design of the XIncludingReader highlights the composability that was our goal when we originally shipped the XmlReader. One can layer readers on top of each other augmenting their capabilities as needed. We will definitely be emphasizing this more in Whidbey.

The third custom reader I've seen this month is the XPathReader. Nothing has been published about this class so far but I'm in the process of putting together an article about it which should show up on the MSDN XML Developer Center at the end of this week or early next week. The whet your appetite imagine an XmlReader that allows you to read XML in a forward-only, streaming manner but allows you to match XPath expressions based on the subset put forward by Arpan Desai in his paper Introduction to Sequential XPath. The following is a sample of how the XPathReader can be used

XPathCollection xc = new XPathCollection();
int query1 = xc.Add('//book/title');

XmlTextReader reader = new XmlTextReader("books.xml");
XPathReader xpathReader = new XPathReader(reader, xc);

while (xpathReader.ReadUntilMatch()){

   Console.WriteLine("Title={0}", xpathReader.ReadString());
}

I should be done with getting the article reviewed and the like in the next few days. April's definitely been the month of the XmlReader.

 

In response to a post about tunneling variables in XSLT 2.0 on the Lambda the Ultimate weblog, Frank Atanassow writes

The markup language community is notorious for reinventing and duplicating concepts and terminology, sometimes even their own. Thus they have "minimum literals" rather than "string literals", "parameter entities" rather than "macros", "templates" rather than "procedures" or "functions", "validate" rather "type-check", "data binding" rather than "translation", "unmarshal" rather than "parse" et cetera.

I suspect that a lot of this is due to sins of omission instead of sins of commision. People in the markup world just aren't that aware of what's going on in the world of programming languages [or databases] and vice versa. I have to deal with this a lot at work.

Thanks to Joshua Allen for pointing out this comment to me.

 

 

In his post Why not standardize an Object Schema? Jason Mauss writes

I was listening to the latest .NET Rocks! episode; the part where they were discussing Service-Oriented systems. I don't remember exactly who-said-what but I do remember what was said. There was mention of something like, “You only want to pass XML messages back and forth, not objects.” The reasoning behind this (IIRC) had to do with interoperability. Let's say you have a .NET caller and a J2EE caller. Since they both define objects differently (and perhaps create and expect different serialized representations of objects) it's not gonna work. This got me thinking, why not have someone (like say, the W3C w/ the help of people at Sun, IBM, MS, etc.) develop a standard “object” schema for Web Services (and SO systems) to pass back and forth?

For example (this is just off the top of my head and not thought through well):

<object type=““ basetype=““>
   <property name=““ value=““ />
   <method name=““ accesstype=”” address="">
     <parameters>
        <parameter name="" type="" required="" />
     </parameters>
   </method>
</object>

I realize this is a huge simplification of what the schema might actually look like, but perhaps someone could provide me with some insight as to why this would or wouldn't be a good idea.

There are a number of points to tackle in this one post. The first is the misconception that XML and service orientation are somehow linked. Service orientation is simply a state of mind, go back and read Don's Don's four fundamentals of service orientation;

• Boundaries are explicit
• Services are autonomous
• Services share schema and contract, not class
• Service compatibility is determined based on policy

None of these explicitly rely on XML, except for the part about services sharing schemas and contracts not classes but XML isn't the only data format with a schema language. Some people such as Sun Microsoystems like to point out that ASN.1 schemas and binary encodings fit this bill as well. The key point is that you should be passing around messages with state not executable code. The fundamental genius of the SOAP 1.1 specification is that it brought this idea into the mainstream and built this concept into its very core. The original spec has this written into its design goals

 A major design goal for SOAP is simplicity and extensibility. This means that there are several features from traditional messaging systems and distributed object systems that are not part of the core SOAP specification. Such features include

• Distributed garbage collection
• Boxcarring or batching of messages
• Objects-by-reference (which requires distributed garbage collection)
• Activation (which requires objects-by-reference)

Once you start talking about passing around objects and executable code the system becomes much more complex and much more tightly coupled. However experience from enterprise messaging systems and global distributed systems such as the World Wide Web show that you can build scalable, loosely coupled yet powerful applications in an architecture based on passing around messages and defining a couple of operations that can be performed on these messages. Would the Web be as successful if to make web requests you had to fire up Java RMI, DCOM, CORBA or some equivalent instead of making HTTP GET & HTTP POST requests over network sockets with text payloads?

Now as for Jason's schema, besides the fact that doing what he requests defeats the entire purpose of claiming to have built a service oriented application (even though the term is mostly meaningless anyway) the schema is missing the most important part. An object has state (fields & properties) as well as behavior (methods). Service oriented architectures dictate that you pass around state while the methods exist at the service end point, (e.g. an HTTP GET or HTTP POST request sends some state to the server either in the form of a payload or as HTTP headers which are then operated upon by the server which sends a result after said processing is done). Once you start wanting to send behavior over the wire you are basically asking to send executable code. The question then becomes what do you send; MSIL, Java byte codes, x86 instructions or some new fangled binary format? When you finally decide that all you would have done is reinvent Java RMI, CORBA, DCOM and every other distributed object system but this time it uses the XML magic pixie dust.

 

Am I the only one saddened by the fact that it's been over four years since Microsoft and IBM co-submitted the XInclude NOTE and the spec is still just a Candidate Recommendation? How about the fact that the W3C Query Languages workshop which led to the creation of the XQuery working group was held almost six years ago and the XQuery specification is still a Working Draft which means it is still a year or two from being done.

This lateness in delivering specs in combination with the unnecessary complexity yet lack of features of other W3C technologies such as XML Schema makes me feel more and more that the W3C is more of a hinderance to the world of XML development than a boon at this point.

Many feel that there isn't any alternative but grinning and bearing it. I wonder if that is truly the case and whether individual or community based innovation such as has happened with technologies like RSS or EXSLT isn't the way forward.

 

Ted Neward, James Robertson and a few others have been arguing back and forth about the wisdom of preventing derivation of one's classes by marking them as sealed in C# or final in Java. Ted covers various reasons why he thinks preventing derivation is valid in posts such as Uh, oh; Smalltalk culture clashes with Java/.NET culture... , Unlearn Bo... and Cedric prefers unsealed classes. On the other side is James Robertson who thinks doing so amounts to excessively trying to protection developers in his post More thoughts on sealed/final. 

As a library designer I definitely see why one would want to prevent subclassing of a particular type. My top 3 reasons are

1. Security Considerations: If I have a class that is assumed to perform certain security checks or conform to certain integrity constraints which is depended upon by other classes then it may make sense to prevent inheritance of that class.

2. Fundamental Classes: Certain types are so fundamental to the software system that replacing them is too risky to allow. Types such as strings or numeric types fall into this category. An API that takes a string or int parameter shouldn't have to worry whether someone has implemented their own “optimized string class“ that looks like System.String/java.lang.String but doesn't support Unicode or stores information as UTF-8 instead of UTF-16.

3. Focused Points of Extensibility: Sometimes a object model is designed with a certain extensibility points in which case other potential extensibility points should be blocked. For example, in System.Xml in Whidbey we will pointing people to subclass XPathNavigator as their way of exposing data as XML instead of subclassing XmlDocument or XPathDocument. In such cases it would be valid to have made the latter classes final instead of proliferating bad ideas such as XmlDataDocument.

There is a fourth reason which isn't as strong but one I think is still valid

4. Inheritance Testing Cost Prohibitive: A guiding principle for designing subclasses is the Liskov Substitution Principle which states

   If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

   although straightforward on the surface it is hard work testing that this is indeed the case when designing your base classes. To test that one's classes truly exhibit this principle subclasses should be created and run through a gamut of tests that the base class passes to see if the results are indistinguishable. Often it is actually the case that there is dependency on the internal workings of the class by related components. There are two examples of this in v1.0 of the APIs in System.Xml in the .NET Framework, XmlValidatingReader's constructor accepts an XmlReader as input but really only supports an XmlTextReader and XslTransform should accept an XPathNodeIterator as output from an extension function but really only supports the internal ResetableIterator. Neither of these cases is an example of where the classes should be sealed or final (in fact we explicitly designed the classes to be extensible) but they do show that it is very possible to ship a class where related classes actually have dependencies on its internals thus making subclassing it inappropriate. Testing this can be expensive and making classes final is one way to eliminate an entire category of tests that should be written as part of the QA process of the API. I know more than one team at work who've taken this attitude when designing a class or set of classes.

That's my $0.02 on the topic. I do agree that most developers don't think about the ramifications of making their classes inheritable when designing them but to me that is an argument that final/sealed should not be the default modifier on a class. Most developers won't remember to change the default modifier regardless of what it is, the question is whether it is more beneficial for there to be lots of classes that one can't derive from or that one can even if the class wasn't designed with derivation in mind. I prefer the latter.  

 

Now that I've gotten Visual Studio.NET 2003 reinstalled on my machine I've been working towards fixing the few bugs I own that have prevented us from shipping a release. The most important bug left to fix is [ 930282 ] Remote storage doesn't actually synchronize state which exists because of laziness on my part.

RSS Bandit gives you the option to download and upload your feed list from a file share, an FTP server or a dasBlog weblog. However this doesn't actually do much synchronization during the import phase, basically it just adds the feeds that don't currently exist in your aggregator. It doesn't synchronize the read/unread messages, remove deleted feeds or remember which items you've flagged for follow up. I am in the process of fixing this for the next release.

I'm currently thinking that we'll break backwards compatibility with this feature. Synchronization will only work between current versions of RSS Bandit. You'll have a choice of two transfer formats ZIP and SIAM. If you select ZIP then we'll synchronize your search folders, flagged items, replied items, subscribed feeds and read/unread message state. All of these will be transferred as a ZIP file. The SIAM option will synchronize subscribed feeds and read/unread message state and will be transferred as a SIAM document. The supported data sources will be WebDAV folder, network share and FTP. I'm interested in any other options people think is interesting to support.

There are a couple of interesting problems to solve before I'm done mostly to do with how to perform the synchronization as quickly as possible. They revolve around scenarios like “What if my work machine has 3 months of posts while my home machine only has 2 weeks of posts in its cache and I synchronize between them?“ or “What happens if I've read different posts from the same feed on my work machine and on my home machine?“. The issue revolve around the fact that replacing the existing information with the incoming information while simple leads to information loss.

This should be fun, I've wanted this functionality for a while.

 

Dimitri Glazkov has produced a JavaScript implementation of DOM Level 3 XPath for Microsoft Internet Explorer. Below are some examples of what using XPath from Javascript looks like with his implementation

Now counting all links on your document is just one XPath query:

var linkCount = document.evaluate( “count(//a[@href])“, document, null, XPathResult.NUMBER_TYPE, null).getNumberValue();

So is getting a list of all images without an alt tag:

var imgIterator = document.evaluate( “//img[not(@alt)]“, document, null, XPathResult.ANY_TYPE, null);

So is finding a first LI element of al UL tags:

var firstLiIterator = document.evaluate( “//ul/li[1]“, document, null, XPathResult.ANY_TYPE, null);

Excellent work. XPath is one of the most powerful XML technologies and getting support for it in clientside HTML scripting is should be a great boon to developers who do a lot of HTML processing using Javascript.  

 

The march towards getting the next official release of RSS Bandit continues, until then you can download the latest version.

The biggest changes since the last beta are that two more language translations have been added, Brazilian Portuguese and Polish. This  brings our number of supported languages to six (English, German, Russian, Simplified Chinese, Brazilian Portuguese and Polish). A couple of bugs with Search Folders were also fixed.

I'm currently the one holding up the release. I've finally gotten Visual Studio.NET 2002 installed on my machine and it seems that I should be able to get Visual Studio.NET 2003 installed today. Once done I'll work on the new installer and implement actual synchronization of feed state using a central server of your choice. Lack of this feature is beginning to get on my nerves.

 

From the Duh! department are the following excerpts from the an interview with the author of Sister's Keeper

In her book, Robbins goes undercover at a college she calls “State U.” during the 2002-2003 school year to find out whether the stereotypes—binge drinking, drug use, eating disorders and promiscuity—are true.

NEWSWEEK: What kinds of things did you witness?
Alexandra Robbins: I really hadn’t expected to find the level of "Animal House" campiness that I did in some groups. They had a tradition called boob ranking where pledges had just a lim­ited amount of time to strip off their shirt and bras to examine each other topless so that by the time the clock was up, they were basically lined up in order of chest size in order of the sisters to inspect. Some sorori­ties hold what they call “naked parties,” during which after a few drinks sisters and pledges strip off their clothes and basically run around the house naked, some of them hooking up with each other before they let the boys in.

NEWSWEEK: Isn’t there a constant emphasis on boys?
Alexandra Robbins: From the mixers to the formals to the homecomings to fraternity parties—there’s frequently a race to get dates from a limited pool of acceptable fraternity guys. And white sororities are so centered on relationships with their ceremonies and rituals and songs to celebrate specific relationship mile­stones. By comparison, in at least one white sorority, the award for getting the highest GPA was a bag of potato chips. And you have to wonder what’s the point of a girls-only organization if it revolves around men.

NEWSWEEK: How prevalent are eating disorders?
Alexandra Robbins: I had heard urban legends about plumbers having to come clean out the pipes ever month or so in sororities because they get clogged with vomit. A lot of girls told me that was true. Eating disorders are so popular that some houses have puking contests after dinner. At State U., every sin­gle one of the 18 sororities had eating-disor­der problems.

The entire premise of the book reminds me of an episode of the Maury Povich show, an excercise in voyeurism.

 

In Christoph Schittko's post about CapeClear's latest WSDL editor he writes

CapeClear recently released a new version of their free WSDL editor. The new version allows adding XML Schemas which, in my mind, was definitely a much needed feature...The only gripe I have is that the new version is no longer called WSDL Editor. Now it's the SOA editor

SOA is now a much overhyped and meaningless buzzword. The entire industry is hyping XML Web Services all over again without pointing out anything of much concrete worth. Microsoft is right up there as well with publications like Microsoft Architects Journal whose last issue had 3 of 5 articles with "Service Oriented" in the title with at least one other being probably the quintessential work on Service Oriented Architecture, Metropolis.

There are basically only 2 people's whose opinions about the mostly meaningless Service Oriented hoopla I consider worth anything. Pat Helland who was talking about service oriented architecures before the buzzword had a name and Don Box because he's the first person I've seen do a decent job of trying to distill the service oriented fundamentals (see A Guide to Developing and Running Connected Systems with Indigo).

Don's fundamentals

• Boundaries are explicit
• Services are autonomous
• Services share schema and contract, not class
• Service compatibility is determined based on policy

make a lot of sense to me. The only problem I have with Don is that he is working on Indigo which is anything from 1.5 to 2 years from shipping depending on who you're listening to but Microsoft is pimping SOA today. I've talked to him about doing a bit more writing service oriented development with existing technologies and even offered to cowrite if he can't find the time. Unfortunately I've been really really busy (we are short one PM and a dev on my immediate team, speaking of which WE ARE HIRING!!!) so haven't been very good at nagging him to do more writing. Hopefully once we lock down for Whidbey beta 1 I'll have some free time until the beta 2 deluge begins.

 

My buddy Josh Ledgard has a posts on the search for the best way to provide online discussion forums on Microsoft technologies for our customers. He has two posts that kick of his thoughts on the issues; MVP Summit Views and Issues with Threaded Discussions and Brainstorming Results of Online Discussion Solutions. In the former he basically states that during the MVP Summit the major feedback he got from MVPs was that they want discussions in an online forum to have all the functionality of NNTP newsgroups and newsreaders provide today (offline capability, watches, authentication & identification, etc) but they don't like the amount of traffic in the NNTP newsgroups. 

Josh's second post mainly tries to address the fact that a number of groups at Microsoft felt that newsgroups are a low tech solution and have ended up creating alternate online forums such as the ASP.NET forums and GotDotNet message boards. This basically has fragmented our developer support experience and is also problematic for product teams since we need to monitor multiple online venues using multiple tools.

My simple suggestion is that the various Microsoft forums should emit RSS that fully supports the Comment API and wfw:commentRss then developers will step up to the plate and create online or desktop aggregators that combine both the NNTP newsgroups and the Web forums. One of the reasons I plan to add NNTP support to RSS Bandit is exactly because I now have to use 3 different tools to monitor our developer forums (Outlook for mailing lists and to get alerts from Web forums, Outlook Express for NNTP newsgroups and RSS Bandit for blogs). There's no reason why I can't collapse this into two tools or even one if one uses something like Newsgator.

Josh and I are supposed to have lunch tomorrow. I'll see what the Visual Studio team is thinking of encouraging in this direction if anything.

 

In his post Or, maybe more strict Phil Ringnalda writes

I've been idly thinking about starting a campaign to get RSS/Atom aggregator authors (and validator authors, as well) to be a little less strict and dogmatic about what feed content is uniformly evil, and must be stripped out in all cases. We have a roughly shared (and mostly unexamined) set of standards, mostly based on Mark Pilgrim's groundbreaking post, saying that you should never allow, among other things, any Javascript, any CSS styles, or any object or embed elements
...
But, the inevitable but: the more you look, the more evil there is in the world
...
Or, say you have a Windows program embedding the IE browser control. You've carefully managed your security zone, so objects are no more dangerous than they are in general, you only display one entry at a time so CSS is no danger, and you've built your own popup blocker so you don't have any reason to strip Javascript. Then I come along again (maybe you should just refuse to subscribe to any of my feeds?), and drop in a simple little paragraph: <p style="height: expression(alert('gotcha'))">.

To the best of my knowledge none of these things is a problem for RSS Bandit. As Phil points out in his post when you embed the IE browser control, you can actually either choose your security zone which is exactly what RSS Bandit does. By default RSS Bandit disables Javascript, ActiveX and Java applets. This is fully configurable by end users because we provide the option to change the web browser security settings use by RSS Bandit.

 

I saw the trailer for the movie I, Robot last night when I went to see Kill Bill Volume 2. For a few seconds into the trailer I thought it was the movie treatment of Caves of Steel, but shortly realized that Asimov's 3 laws of robotics had been turned into scaffolding to hang a stereotypical Will Smith action movie off of (Bad Boys with robots).

They could have done a lot more with the mountains of material Isaac Asimov produced. What a disappointment.

 

 

 

She Bangs, She Bangs

 

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.

 

This week was the 2004 MVP Summit, where several hundred MVPs for various Microsoft technologies and products descended on Redmond to interact with the various product teams at Microsoft. It was a little hectic organizing things to ensure that the XML MVPs got enough face time but I think everyone was happy with the way things turned out.

On Monday, a number of Microsoft folks and MVPs had dinner at Rikki Rikki, a rather nice sushi restaurant in Kirkland, WA. The geeks in attendance included Tim Ewald, Ted Neward, Don Box, Rory Blyth, Kirk Allen Evans, Drew Marsh, Julia Lerman, Jeff Julian, Sam Gentile, Joshua Allen, Chris Anderson, Arpan Desai, Mark Fussell, DonXML Demsak, Daniel Cazzulino,  Aaron Skonnard , Christoph Schittko, Rick Strahl, Joe Fawcett, Peter Provost, Cathi Gero, Michael Rys, Bryant Likes, Jeffrey Richter and a number of others. The dinner was Kirk's idea and Don suggested the place, it was definitely a pleasant evening talking XML geekery. One of the things we talked about was why some of the APIs that were in the PDC preview won't make it to Whidbey such as the XmlAdapter and the XPathChangeNavigator.  In retrospect the functionality provided by both APIs was complex to implement yet could be satisfied through other mechanisms.

At the end of the dinner Kirk took a group photograph. Afterwards a couple of us stragglers saw the movie Hellboy which was an entertaining super hero movie although the ending could have been better.

On Wednesday, eight XML MVPs (DonXML Demsak, Joe Fawcett,  Daniel Cazzulino, Jeff Julian, Matevz Gacnik, Rolandas Gricius, Bryant Likes, and J. Michael Palermo IV) got to spend a day with the WebData XML team. Shortly after 9 AM there was an hour long open panel discussion with the MVPs on one side and a few dozen members of the WebData XML team on the other with questions flying back and forth. For many members of the team, getting candid feedback from an array of customers with different backgrounds was very illuminating. The rest of the day was filled with presentations and Q & A sessions with the MVPs. They got a preview of what we'll be doing in Whidbey and maybe Orcas in the area of XML tools, XML<->Relational mapping technologies, XQuery and core XML APIs. Since one of the complaints we'd heard was that a number of sessions they'd seen earlier in the week were just rehashed PDC slides I endeavored to ensure that MVPs would see newer content or at least get more in depth information about what we plan to do. Based on the feedback I got they were pleased with the experience.

On Friday, Robert Scoble and Charles Torre swung by my office and interviewed me for Channel 9. I gave them a tour of my office and showed them my budding collection of Spawn action figures and my demotivators hanging on the wall. I'm not sure if I gave a good interview or not but I guess that's part of the charm of Channel 9. I'll post a link to the interview whenever it shows up online.

 

I'd like to congratulate Robert Scoble , Jeff Sandquist and all the others involved on the launch of Channel 9. The doctrine of Channel 9 positions it as an avenue for Microsoft employees and their customers to interact in an honest manner. The Who We Are page states that it is an "attempt to move beyond the newsgroup, the blog, and the press release to talk with each other, human to human".

My personal take on Channel 9 is that it reminds me a lot VBTV, people either really liked it or really hated it. Already I've begun to see posts from both ends of the spectrum, there are posts like Channel 9 - a very commendable effort and then those like Why Channel 9 is stupid. I tend to agree with the latter post but do think it is an interesting experiment.

I think Microsoft has been doing a good job of providing avenues for its employees to interact directly with their customers from newsgroups to blogs to the various developer websites such as MSDN and ASP.NET. If anything I feel like there are probably too many options than too few. I daily check the microsoft.public.dotnet.xml newsgroup, microsoft.public.xml newsgroup, the Extreme XML message board on MSDN, various blogs I'm subscribed to, the comments in my work blog as well as various internal mailing lists for feedback on the technologies I am responsible for. Then there are days like yesterday when I got to hang out, drink beer and eat sushi with Tim Ewald, Ted Neward, Don Box, Rory Blyth, Kirk Allen Evans, Drew Marsh, Julia Lerman, Jeff Julian, Sam Gentile, Joshua Allen, Chris Anderson, Arpan Desai, Mark Fussell, DonXML Demsak, Daniel Cazzulino, Drew Marsh,  Aaron Skonnard , Christoph Schittko, Rick Strahl, Joe Fawcett and a bunch of others.

The thought that Microsoft needs to “beyond the newsgroup, the blog, and the press release” doesn't jibe with my experiences interacting with our customers in my daily experience. In fact, I know a number of our customers dislike the fact that there's a decision tree that needs to be traversed to figure out how to get information from Microsoft (do they got to newsgroups? MSDN? find the relevant blog? go to GotDotNet? call PSS? etc). 

However as I mentioned earlier, I think it is an interesting experiment which means I will participate to some degree. I'm already scheduled to do an interview with Scoble this Friday so I'll probably be hamming it up in one of those streaming videos in the next few weeks.

Work calls.

 

Joshua Allen has a post entitled RSS Last Mile where he complains about the lack of a clear story with regards to one click subscription to RSS/ATOM feeds. I wrote about the various approaches to achieving one click subscription to ATOM and RSS feeds a few months ago which led to drafting feed URI scheme. Three months later, one click subscription to syndication feeds is still as confused as it's always been. A lot of the major aggregators support the feed URI scheme but none of the major blogging tools has decided to support it yet. Instead a lot of folks still use the 127.0.0.1 hack popularized by Radio Userland but which is now utilized by a wide number of aggregators. However most websites just do nothing with regards to one click subscription and just have a hyperlinked image, such as , which points to the RSS feed. 

The only new thing I've seen is that yet another person has cooked up their own one click subscription scheme that is incompatible with all the others. Thanks to Joshua's post I found an RFC for one click subscription to syndication feeds which seems to me to be the least advantegeous of the approaches that have shown themselves thus far.

The author of the RFC wrote the following about existing approaches, I've annotated his comments with mine in red text

Current solutions:

• have the aggregator clients register with some mime-type (for either RSS or OPML), I don't believe anyone's actually implemented this since most aggregator authors know this doesn't work for a variety of reasons listed in my post on one click subscription to ATOM and RSS feeds
• have a new protocol (feed:), actually this is a URI scheme not a protocol, and the process is the same as the above, have the aggregator clients register with as the handler for some URI scheme
• support as many clients as possible via javascript (see QuickSub),
• transform the RSS with XSL in the browser to help newbies (no really a one-click subscription solution though).This could be a one click subscription option if the prettied up RSS feed shown to the user also displays a link that uses one of the other 3 techniques mentioned above. So this approach is really orthogonal to the others and in fact can be considered complimentary

The author of the RFC post then goes on to suggesting an Internet Explorer specific solution namely that

Replace the orange Feed button:
The orange feed button needs to be wrapped with an object tag:

<object classid="clsid:0123456789ABCDEF [1]">
  <param name="feedurl" value="http://feedurl [2]">
  <param name="description" value="blah blah [3]">
  <param name="imageurl" value="http://buttonimageurl [4]">
  <a href="http://feedurl [2]"><img src="http://buttonimageurl [4]" /></a>
<object>

If the ActiveX control with class ID [1] is installed, it displays a custom "subscribe" button. When you click on it, it uses the feedurl parameter [3] to subscribe.

Besides the fact that this approach is Internet Explorer specific since it requires an ActiveX object it doesn't offer anything that the other approaches don't.  I don't see why Joshua thinks it's a good idea, considering that all 3 of the other approaches work in a variety of browsers on a variety of platforms.

 

 

I finally got to take a look at the WS-MetadataExchange specification while hanging out in Don's office last week. The spec is fairly straightforward, it defines a mechanism for one to request the WSDL, Policy or XML Schema of a target namespace (i.e. a URI) from an XML Web Service endpoint. Basically one can ask what services an endpoint supports and what the messages the end point accepts should look like. 

Both Don and Omri have suggested that WS-MetadataExchange can solve a problem I had with the SOAP-based version of the ATOM API. The problem is how an ATOM client is supposed to know what services an ATOM end point supports. Here are three descriptions of ATOM-enabled sites that I might want to interact with as an RSS Bandit user.  

1. A weblog that supports user comments posted anonymously and provides the ability to search the weblog archives. The user comments must use a subset of HTML. For example, Sam Ruby's weblog.

2. A weblog that doesn't have comments enabled but does provide the ability to search the weblog archives. For example, Mark Pilgrim's weblog

3. A weblog that only supports comments that have been authenicated with TypeKey and doesn't support search.  Again user comments must use a subset of HTML. Any Movable Type blog that supports TypeKey is an example.

All three would require a smart client to give the user visual hints and clues as to how they can interact with the site. At the very minimum a search box that is grayed out when the target weblog doesn't support search.

So far the only mechanism I've seen proposed for solving this problem in the case of the ATOM API is the link element used for locating service endpoints. This allows you to get the URI of service end points like where to post comments or where to send search results if they exist but do not answer finer grained questions. Questions such as “What subset of HTML can I use in comments?” or “Do I need to be authenticated before I post comments” are currently not answered by any of the draft ATOM specs.

So far WS-MetadataExchange or something like it look like the best way to support such scenarios for SOAP-enabled ATOM end points in a way that is consistent with the Global XML Web Services architecture. I would be interested in seeing an ATOM-specific solution evolve as well since some of this issues hurt usability of weblogs. I've lost count of the amount of times I've posted a comment or seen someone post a comment only to complain about the fact that the weblog doesn't support HTML or mangled some text. Having a way to inquire about this in a standard way would definitely improve the user experience.  

 

This week Torsten figured out how to get the equivalent of “Subscribe in RSS Bandit” to the context menu in Internet Explorer and Firefox when you right-click on a link. Click below for a screenshot of what it looks like in Internet Explorer.
 

It seems the more popular hip hop gets the more I hate the stuff that gets played on the hip hop radio stations. I particularly cringe whenever I hear J-Kwon's “Tipsy” or Kanye West's “Through the Wire”. It seems I've begun to retreat into the past or listen exclusively to mix tapes. Select tracks from the following albums have been playing semi-regularly on my iPod in the past few weeks

• DJ Green Lantern - Invasion Part II / Conspiracy Theory

• Jay Z - Reasonable Doubt

• G Unit - God's Plan

• PM Dawn - The Best of PM Dawn

A friend of mine suggested picking up a Linkin Park album but I'm not sure where to start. I have heard their collaboration with the X-Ecutioners on It's Goin' Down and I liked it. So the question is whether to go with their last album or their first album.

 

I am subscribed to the Amazon Hip Hop Music RSS feed which provides information about available hip hop CDs on sale at Amazon. I was just thinking that it'd be really cool if once a CD I liked showed up in my RSS feed I could just click a [Buy This] button and initiate the process of purchasing the CD. Combining this with Amazon's one click shopping it's conceivable that this could be done in a single click.

At the minimum to implement something like this you'd need an annotation in the RSS feed that contained the end point for the aggregator to submit the purchase information securely and a specified format for what the submitted purchase information should look like. In the case of Amazon, it might just be a cookie while for others it might be the all the required information like credit card number and shipping address.

Now that would definitely be cool. A subscription to a list of things I might be interested in buying and the ability to buy one of them when something caught my eye.   

 

 

I heard D12's My Band on the radio and was wondering if this is the harbinger of a new album by Em or D12. The song is the typical kind of over-the-top rap you get from D12, the premise is that the rest of D12 is jealous of Em cause he gets more money and fame then them.  

I guess I need to swing by a CD store and see if I can get any news that way.

 

A little while ago I noticed the SAX dot NET project was announced on the XML-DEV mailing list. From the desxcription on the project page

SAX dot NET is a C# port of the original Java based SAX API specifications. When compiled into a .NET assembly it becomes available to the other .NET languages as well.

The .NET Framework doesn't ship with an implementation of a SAX push model XML parser but instead ships with the pull-model parser in the form of the System.Xml.XmlReader class. The primary reasons for this can be gleaned from my article A Survey of APIs and Techniques for Processing XML where I list the pros and cons of various approaches for processing XML. The main advanatages a pull-model XML parser like the XmlReader have over a push model XML parser like SAX are

Pull model parsers typically do not require a specialized class for handling XML processing since there is no requirement to implement specific interfaces or subclass certain classes for the purpose of registering callbacks. Also the need to explicitly track application states using boolean flags and similar variables is significantly reduced when using a pull model parser

I can understand that developers migrating to the .NET Framework from Java platforms or MSXML would like to have the familiar feel of the SAX API so I definitely welcome such projects. However I have seen some criticism of the project from Daniel Cazzulino, a Microsoft XML MVP, in his post Do we need SAX for .NET? (or does Java ports to C# make sense?) he points out of some of the disadvantages of blindly porting an API from one platform to another. He points out some inconsistencies and redundancies between SAX dot NET and the .NET Framework such as

• There  is an XmlNamespaces class that does the same thing as the System.Xml.XmlNamespaceManager class

• There are IAttributes AND IAttributes2, and the corresponding implementations called AttributesImpl and AttributesImpl2 which seem to imply interface versioning problems and legacy issues in a brand new project.

• The existence of non-standard delegates such as OnPropertyChange(IProperty property, object newValue)  instead of the  typical pattern in the .NET world where it should be OnPropertyChange(object sender, ProperyChangeEventArgs e).

I think Daniel raises good points and encourage any developer porting an API to the .NET Framework to endeavor to make it consistent with the patterns and naming conventions in the .NET Framework. Doing so makes it easier for developers to understand how to use the API since it will be familiar and contains few surprises.