Why I like XML

Monday, July 10, 2000 by Dave Winer.

Intro 

This piece serves two audiences, so it may not seem like a DaveNet piece, it might seem more like a column for XML Magazine, because that's what it is.

I'm going to digress. XML is a new magazine published by Jim Fawcette and edited by Steve Gillmor. I knew Jim when he was an editor at InfoWorld in the early 80s. Now he's a media magnate, because he figured something out that no one else did, that there are a lot of Visual Basic programmers, and no one knew how to (or wanted to) make magazines and conferences for them. Jim did that, and it worked. Now he's branching out and showing up in lots of powerful places. Now he starts new magazines and I write for him. I find that very interesting.

Steve Gillmor, who promises not to edit me, is an interesting character too. He's Dan Gillmor's older brother. Talking with Steve I can hear Dan's accent in his voice. I said "Steve, you sound like Dan!" A bit of a groan. Ooops. I understand, I have a younger brother too.

Anyway, to the XML Magazine readers, my name is Dave Winer. I run a Web tools and publishing company called UserLand. We make a publishing platform called Frontier, and an easy-to-use browser based Web application for editing sites called Manila. The software runs on Windows and Mac, Unix coming soon. Our goal is to turn the Web into a great group writing environment; we actually believe we've already done that.

I've been a software developer for 25 years. I did stuff for Unix, CP/M, the Apple II, IBM PC, Mac and Windows. I've written outliners, an object database, script interpreter, development tools, a content framework, and now HTTP servers and clients. I am also a writer, having been a columnist at Wired, and have written for the Web since 1994.

I co-designed SOAP, which is the protocol underneath the Microsoft Dot-Net platform. I like working with Microsoft. We also work with Mac and Windows developers and members of the open source community, but not the zealots, and only people with open minds. Now I'm going to tell you why I like XML.

Why I like XML 

I like XML because I like choice, not just for me, but for people who use my software.

I like choice because that means I can sell products and services without worrying about being crushed by a platform vendor. I like developing for the Internet, which I think of as the platform without a platform vendor. In other words there's no one who can crush me here. That's good!

Now, for the last six to eight years, developing for the Internet meant developing for the Web. You'd write server applications that run on any operating system that can host HTTP applications, which is basically every operating system. Users of your applications could use any operating system that had a Microsoft or Netscape browser (the two browsers supported by most Web apps) which, again, is most operating systems.

This was great because it meant there was no such thing as Windows or Mac or Unix software, there was just Web software. But like any apparent panacea, it wasn't so great, because the applications had limited user interfaces. There were attempts to fix this by adding Java and DHTML to the browser, but it always came up way short of the user interface techniques that we already knew.

It was a puzzle. Why do I like the Web so much when it's so funky? I spent five years figuring that out. In 1996 I learned that the Web is groupware. Real-world websites are collaborations of designers, writers, programmers, graphics people, and users. Anything short of groupware is going to come up short.

Then we spent two years porting our publishing software to Windows. I hate porting, it's a waste of time, but our home platform, the Macintosh, was in constant confusion, and the people we wanted to reach were using Windows, in droves. So we ported.

Some time in 1998 I decided to start editing my home page, then other parts of my website, in a Web browser. It was fantastic! Before that I had used a check-out-check-in system, the same kind of software that programmers use to manage application development as groupware.

Making the switch to editing in the browser had one huge benefit. I no longer had two locations for my writing. When I noticed a mistake on my site, I clicked the Edit This Page button, made the change, clicked another button and the change was made. I didn't have to memorize two locations for the content, one for reading and one for writing. And there were no mistake-prone 18-step processes for updating the site. Three steps is all it takes, and that's nirvana for a Web writer.

(And even better, I didn't have to bother a grouchy site administrator. I could do all the editing myself.)

Now here's something even weirder. Writing in a Web browser is wonderful but it also sucks. In other words, the Web browser is the best place to edit copy for the Web, but it's also the worst. Why? Because the editing tools in the browser are the worst. No Find-and-Replace or Undo, none of the elegance of the great desktop writing tools of the Mac and Windows.

So how could I get the best of both worlds, a great writing tool with integrated networking? Believe it or not, that's what lead me to XML.

XML over HTTP 

We were already working on ways to connect servers using a protocol called SOAP, which we designed with Microsoft and Developmentor starting in Spring 1998, but we hadn't thought of using SOAP to connect writing tools to servers until the summer of 1999.

The reasoning went like this. What makes the browser such a great network editing tool? Answer -- it understands HTTP at its core. What if we made a desktop writing tool that understands HTTP at its core? What would that look like? How would it work?

Here's what we came up with. In the browser, right under the Edit This Page button, is another, smaller button that says PIKE, which is the name of our desktop editor. Click on the button and the server sends the contents of the story to the editor. It opens in a window. The editor comes to the front. You edit, the normal way, using all its wizzyness, drag and drop, expand and collapse, reorganization and annotation, all the things no Web browser is ever going to do (at least not in our lifetimes).

But what do you do when you want to update the copy on the server? How complicated should that be? Well, luckily your braincells are already programmed to know how to do this. Pull down the File menu and choose Save. That's it. As with the browser-based editor, we worked, even hacked, at simplicity. We don't think it can get much simpler than this, and simplicity is the single biggest thing that's in the way of the Web as an easy writing environment.

Now what does this have to do with XML over HTTP and SOAP? Well, that's how it works. That's how the workstation application and the server are connected. So in this context, XML is simply enabling technology, but it's worth lifting the hood, because the way it enables is very different, because it is open.

XML can be open 

The articles in the rest of this magazine, which I have not seen, probably make XML seem very complicated. But it is not complicated. You can ignore most of what they tell you about schemas and namespaces and parsers and whatever. It's meaningless. If it ever gets widely deployed, the details will be hidden behind middleware interfaces, because basically it is only comprehensible to a very small number of people who care.

The important thing about XML is that it means that your software can be replaced. Now this may not sound like an advantage, unless you work for a software vendor who's being sued for antitrust, but it actually is an advantage for everyone. Because users have choice, there are fewer reasons for them to wait. And we can have diversity. Not only will there be desktop editing tools for Windows, but there will be equivalent tools for people who use Macs. Maybe someday Unix will be a great writing platform, or maybe something revolutionary and wonderful will come along that no one has ever heard of that you'll want to use to edit your Web site. In the software business you never can tell what's coming next, and with open interfaces the new things can easily be compatible with the old.

Further, no company or individual, no matter how mighty they are, can do everything well. Some make great servers, others make great editors. And there are all kinds of editors, from page layout programs, graphics editors, flowcharters, outliners, spreadsheets, presenters, and on and on. People should be able to use any kind of tool to edit content for the Web, even things we haven't thought of yet, and they should automatically plug in. Again, open interfaces make that possible.

The beauty of XML is that it's *possible* to make open interfaces with it. It's not automatic or inevitable, so you should ask your vendors if they are working with their competitors on plug-compatibility. Make it an issue when you decide which tools to use. Because if you have choice, you can never be left behind.

Dave Winer