IE7 Transforms Atom to RSS 2

I put a little mileage on IE7 feeds today.

First this Wellstorm Atom feed. Of note: a) it validates on Feed validator; b) it uses an extension namespace; c) it specifies a CSS stylesheet.

I've pasted in the relevant files below.

Observations:

IE7 uses its own stylesheet, ignoring mine. That's ok I guess; it's a smart client, so it should be styling to suit its own purposes.

Before you subscribe, View Source: It displays the Atom xml content.

After you subscribe, View Source: IE7 has transformed the Atom to RSS 2.0.

Unfortunately, within IE7 you can never again view the original atom file! You can't enter the URL and View Source... it always shows it transformed to RSS. Weird.

Here is the Atom feed:

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet href="http://www.hughw.net:8080/witsml/styles/atom.css" type="text/css"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:wixp="http://www.wixp.org/ns/atom">
  <id>http://www.hughw.net:8080/witsml/atom/Default%20Repository/!well</id>

  <title>WITSML Repository</title>

  <updated>2006-03-17T14:01:14.935-06:00</updated>

  <link rel="self" href="http://www.hughw.net:8080/witsml/atom/Default%20Repository/!well"/>

  <entry>
    <id>http://www.hughw.net:8080/witsml/atom/Default%20Repository/well.W-12</id>
    <title>6507/7-A-42</title>
    <link href="http://www.hughw.net:8080/witsml/atom/Default%20Repository/well.W-12.rby" rel="http://www.wixp.org/rel/contains"/>
    <updated>2001-05-31T08:15:00.000000+00:00</updated>
    <published>2001-04-30T08:15:00.000000+00:00</published>

    <author><name>John Smith</name></author>
    <wixp:ObjectType>well</wixp:ObjectType>
    <wixp:LastModified>2006-03-17T14:01:14.935-06:00</wixp:LastModified>
    <wixp:Name>6507/7-A-42</wixp:Name>
    <wixp:uidWell>W-12</wixp:uidWell>
    <wixp:nameSource>John Smith</wixp:nameSource>

    <wixp:dTimStamp>2001-05-31T08:15:00.000000+00:00</wixp:dTimStamp>
    <wixp:dTimCreation>2001-04-30T08:15:00.000000+00:00</wixp:dTimCreation>
    <wixp:dTimLastChange>2001-05-31T08:15:00.000000+00:00</wixp:dTimLastChange>
    <wixp:itemState>Plan</wixp:itemState>
    <wixp:comments>These are the comments associated with the Well data object.</wixp:comments>
    <summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><a href="http://www.hughw.net:8080/witsml/atom/Default%20Repository/well.W-12">well 6507/7-A-42</a> <a href="http://www.hughw.net:8080/witsml/atom/Default%20Repository/well.W-12.rby">[contents]</a></div></summary>

    <content src="http://www.hughw.net:8080/witsml/atom/Default%20Repository/well.W-12" type="application/x.witsml+xml"/>
  </entry>
</feed>

Here is the IE7 persisted version:

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"
    xmlns:cf="http://www.microsoft.com/schemas/rss/core/2005">
    <channel>
        <guid isPermaLink="false">http://www.hughw.net:8080/witsml/atom/Default%20Repository/!well</guid>
        <title cf:type="text">WITSML Repository</title>
        <pubDate>Fri, 17 Mar 2006 14:01:14 GMT</pubDate>
        <atom:link href="http://www.hughw.net:8080/witsml/atom/Default%20Repository/!well"
            rel="self"/>
        <item>
            <guid isPermaLink="false"
                >http://www.hughw.net:8080/witsml/atom/Default%20Repository/well.W-12</guid>
            <title xmlns:cf="http://www.microsoft.com/schemas/rss/core/2005" cf:type="text"
                >6507/7-A-42</title>
            <atom:link xmlns:atom="http://www.w3.org/2005/Atom"
                href="http://www.hughw.net:8080/witsml/atom/Default%20Repository/well.W-12.rby"
                rel="http://www.wixp.org/rel/contains"/>
            <pubDate>Thu, 31 May 2001 08:15:00 GMT</pubDate>
            <atom:published xmlns:atom="http://www.w3.org/2005/Atom">Mon, 30 Apr 2001 08:15:00 GMT</atom:published>
            <author>John Smith</author>
            <atom:author xmlns:atom="http://www.w3.org/2005/Atom">
                <atom:name>John Smith</atom:name>
            </atom:author>
            <wixp:ObjectType xmlns="http://www.w3.org/2005/Atom"
                xmlns:wixp="http://www.wixp.org/ns/atom">well</wixp:ObjectType>
            <wixp:LastModified xmlns="http://www.w3.org/2005/Atom"
                xmlns:wixp="http://www.wixp.org/ns/atom">2006-03-17T14:01:14.935-06:00</wixp:LastModified>
            <wixp:Name xmlns="http://www.w3.org/2005/Atom" xmlns:wixp="http://www.wixp.org/ns/atom"
                >6507/7-A-42</wixp:Name>
            <wixp:uidWell xmlns="http://www.w3.org/2005/Atom"
                xmlns:wixp="http://www.wixp.org/ns/atom">W-12</wixp:uidWell>
            <wixp:nameSource xmlns="http://www.w3.org/2005/Atom"
                xmlns:wixp="http://www.wixp.org/ns/atom">John Smith</wixp:nameSource>
            <wixp:dTimStamp xmlns="http://www.w3.org/2005/Atom"
                xmlns:wixp="http://www.wixp.org/ns/atom">2001-05-31T08:15:00.000000+00:00</wixp:dTimStamp>
            <wixp:dTimCreation xmlns="http://www.w3.org/2005/Atom"
                xmlns:wixp="http://www.wixp.org/ns/atom">2001-04-30T08:15:00.000000+00:00</wixp:dTimCreation>
            <wixp:dTimLastChange xmlns="http://www.w3.org/2005/Atom"
                xmlns:wixp="http://www.wixp.org/ns/atom">2001-05-31T08:15:00.000000+00:00</wixp:dTimLastChange>
            <wixp:itemState xmlns="http://www.w3.org/2005/Atom"
                xmlns:wixp="http://www.wixp.org/ns/atom">Plan</wixp:itemState>
            <wixp:comments xmlns="http://www.w3.org/2005/Atom"
                xmlns:wixp="http://www.wixp.org/ns/atom">These are the comments associated with the
                Well data object.</wixp:comments>
            <description xmlns:cf="http://www.microsoft.com/schemas/rss/core/2005" cf:type="html"
                ><div><a href="http://www.hughw.net:8080/witsml/atom/Default
                Repository/well.W-12">well 6507/7-A-42</a> <a
                href="http://www.hughw.net:8080/witsml/atom/Default
                Repository/well.W-12.rby">[contents]</a></div></description>
            <content src="http://www.hughw.net:8080/witsml/atom/Default%20Repository/well.W-12"
                type="application/x.witsml+xml" xmlns="http://www.w3.org/2005/Atom"
                xmlns:wixp="http://www.wixp.org/ns/atom"/>
            <cf:id>0</cf:id>
            <cf:read>true</cf:read>
        </item>
    </channel>
</rss>

Lisp for Entrepreneurs

Yet another Lisp is for Entrepreneurs link -- this one from Bill Clementson. Programming languages are converging on Lisp, so I'm bypassing the deep dive on Ruby...

I've gone deep on Lisp recently and I have to tell you: maybe I'm not smart enough to be a Lisp programmer, at least soon enough. I've written a functioning, and reasonably complex, program (a Gibbs sampler for a Bayesian network) but I can hardly read the thing. It's all (car(cdr(assoc('xxx ...)))) ...that design is nobody's fault but my own, but it's just the path of least resistance as I'm writing the thing. I have begun to see a few glimmers of possibilities I don't have in other languages. I've written a macro, and I get it. I've passed lambdas to functions. This code is a a lot terser than a Java version I wrote years ago. Terse is good, right? But I have to comment the code more extensively because it's not really "self describing."

Maybe I'm the sort of weak-natured guy who needs an early-binding language enforcing the discipline up front. 'Cause I have to admit, strong typing makes me write better programs. It's a character flaw.

Microcontent Three-Way Processses

We're all going to have to package our services as microcontent (via Sean McGrath). For those of us in the business of delivering "two-way" data services, our webapps will wither. Good!

Now we have to figure out how to get paid. I can deliver some critical information to you via Atom or RSS. And you have some client subscribing, consuming, and processing that data on your behalf. I need to get paid by subscription, or by the piece. I'll no longer have a webapp where you subscribe or agree to purchase single items, and where I meter your consumption. Aggregators, and successor services like them, will have to do that. So we need extensions to APP to compose three-way transactions.

So you will initiate a subscription via your aggregating service. I'm not neccessarily talking about a feed aggregator; this might be some specialized service in a vertical, like stock quotes. It will collect your personal and payment information. It will contact me to subscribe you. It will send me your PayPal, or whatever, payment authorization. I will respond with approval or denial. When retrieving information on your behalf, your aggregator definitely has to tell me you are retrieving that information, so I can authorize it. Contrast to current practice: aggregators retrieve a feed on behalf of hundreds of anonymous users. And we have to address the issue of whether I trust the aggregator service to tell me the truth, or whether we can design protocols preventing it paying for one subscription when it has sold 20.

To make that happen, we'll need a microcontent business process specification that can compose three-way transactions. And it has to be as simple and transparent as RSS and Atom. I'm not talking about BPSS, although there's a lot to be learned there.

Spooky Rojo Mojo

Alerted by Mark's post that he switched to Rojo, I just now signed up to give it a try. After going through the wizard, I land on my new home feeds page. And my very first "Rojo Feed Recommendation" is: Mark's other blog, Integrate This. And no, I haven't imported my feeds from Bloglines yet!

URIs are opaque, except when they're not

Roy jumps in to clarify the law about URI opaqueness:

The key is that the server is free to tell the client that there does exist structure in a given URI-space, and then the client is free to make use of that knowledge in future requests. That is how server-side imagemaps worked -- HTML says that the URI is structured such that appending "?X,Y" to that URI, where X and Y are non-negative integers, corresponds to points on a map that can respond to future GET requests.

Thus, one way for the server to tell the client that a given URI is structured is to provide the URI in a standard element of a standard media type that has been defined as such. Another is to include the URI in a response header field.

I may be having my own, belated moment of total, violent, zen clarity.

Patterns Problem

Peter Seibel's book has a nice analysis of the "patterns problem":

The reason both these functions start the same way is because they're both test functions. The duplication arises because, at the moment, test function is only half an abstraction. The abstraction exists in your mind, but in the code there's no way to express "this is a test function" other than to write code that follows a particular pattern.

Unfortunately, partial abstractions are a crummy tool for building software. Because a half abstraction is expressed in code by a manifestation of the pattern, you're guaranteed to have massive code duplication with all the normal bad consequences that implies for maintainability. More subtly, because the abstraction exists only in the minds of programmers, there's no mechanism to make sure different programmers (or even the same programmer working at different times) actually understand the abstraction the same way. To make a complete abstraction, you need a way to express "this is a test function" and have all the code required by the pattern be generated for you. In other words, you need a macro.

Lisp, again.