Thoughts on the Applied XML DevCon

I'm back home from the Applied XML DevCon. What a strange trip it was. It was great to spend 4 days with Chris (he took me to/from the airport and I let me stay at his house), see all the guys who still have blue badges and hang out with friends from the XML world that I read all the time but only see a couple times a year, if that. I proposed the XML DevCon idea to Chris way back when he was looking for a topic, having realized that ATL wasn't the future. I've spoken at all 5; this is my favorite conference to attend. It's just a blast.

This one was particularly surreal. By the end of the day the first day, a lot of people were pretty depressed. It seemed like it was all doom and gloom, right from the start of Tim Bray's keynote through Sam's hard lessons on layering technologies over things that aren't baked to the speaker panel after dinner. The speaker panel was particularly unpleasent, at least for me, mostly because we spent a lot of time talking about the problems with XSD.

I've said before that I'd prefer to use RNG, because I think it's easier to learn and closer to the spirit of XML, but I don't expect the industry to switch. If we're going to use XSD, though, we better figure out how to do it without requiring tools This is especially true if people want to do “contract first“ development, which most people said they prefer. I just don't believe that we can use XSD indirectly and exclusively through tooling without understanding how it works. In short, if we're going to use it and want to succeeed, we better understand it. That's not to say we shouldn't use tools to work with XSD, just that we better understand how it works.

A couple people observed that we don't really need XSD to do this stuff. On the one hand, that's true. If you use the raw XML and SOAP APIs in your platform of choice, you can just go code up your services and clients based on whatever documentation you want. But most people aren't prepared to do that. They want to describe their system and have code generated for them. XSD and WSDL, flawed or not, supply that. Some people aren't prepared to write descriptions in those languages, so they look to generate them from code.

The panel discussion left me so bummed out I had trouble sleeping. Mixed with jet lag, a head cold and a 5 month old son, I woke up at 5am. I spent the next 4 hours thinking about of the state of the world and what I wanted to say in my keynote. I kept thinking about the Corrillian guys, who talked about the success they were having with this technology. Sometimes they use the tools, sometimes they do custom stuff. They do what they need to do to make it work. That's exactly how we approached our work on MSDN2.

Sometimes I wonder whether people think I'm just an angle-bracket junky who can't stand using objects or any other tools that vendors give me. The truth is that I use raw XML when I have to in order to get the job done. MSDN2 uses XML extensively, as an internal data model and as APIs. In our problem space, it worked great. We wrote XSD's and WSDLs by hand (contract first!). We generated some code from them, but we wrote most of it by hand because most of system deals with potentially large semi-structured data that the tools map to DOM elements by default. Performance pushed us to hand write a lot of things. If the code-gen tools had done what we needed we would have used them, believe me.

The point is that we did what we needed to do to get the job done, and that's really what my talk was about. After a day hearing from vendors about how XML and Web services don't work and hearing from customers about how they do, it seemed like an important point to make. The vendors will never be done working on tools or technology; they always want to make it better in order to attract customers to their platform. That's exactly as it should be. Meanwhile, you have to do what you need to in order to ship. If you can use a technology to build a system that does what its meant to do, then perfect or not, that technology is a success.

A lot of my talk was about cost vs. benefit, which is how I view the world. If you want to do contract first development and you don't have a tool to create WSDL/XSD descriptions, you can write them by hand. You get a benefit, you pay a cost. It's up to you to decide if it's worth it. A lot of my talk was also about the idea that you should “make it easy for people to pay you.“ If I want you to use my technology, I should make it as easy for you as possible so that benefit is high and cost is low. You can apply this idea to many many things in life.

Anyway, as always, Chris threw a great conference. I look forward to the next one.