All XML based messages are just POX over the wire
Let's take the example SOAP message provded by the W3C.
-
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
-
<env:Header>
-
<n:alertcontrol xmlns:n="http://example.org/alertcontrol">
-
<n:priority>1</n:priority>
-
<n:expires>2001-06-22T14:00:00-05:00</n:expires>
-
</n:alertcontrol>
-
</env:Header>
-
<env:Body>
-
<m:alert xmlns:m="http://example.org/alert">
-
<m:msg>Pick up Mary at school at 2pm</m:msg>
-
</m:alert>
-
</env:Body>
-
</env:Envelope>
Let's break it down into what's important to us.
Stuff we don't care about
-
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
-
<env:Header>
-
<n:alertcontrol xmlns:n="http://example.org/alertcontrol">
-
<n:priority>1</n:priority>
-
<n:expires>2001-06-22T14:00:00-05:00</n:expires>
-
</n:alertcontrol>
-
</env:Header>
-
<env:Body>
Stuff we do care about
-
<m:alert xmlns:m="http://example.org/alert">
-
<m:msg>Pick up Mary at school at 2pm</m:msg>
-
</m:alert>
Stuff we don't care about
-
</env:Body>
-
</env:Envelope>
See all that stuff we don't care about is what I call the message tax. Sometimes, as with TCP/IP messages, it's important to pay the message tax. HTTP headers are another message tax it's pretty important to pay. But consider what we are getting for our dollar when we pay the SOAP, or any other WS* tax. Why do I say that the stuff in the message header is stuff we don't care about? Well, in the context of the user-facing portion of the application, none of that does matter. All that matters is that we can get to the message, the actual payload, parse it out, and do something with it.
I asked Phil a leading question over on his blog. He responded by asking, "...without the end tags, are you sure you got the whole message?". Good point, but we'll find that out when we try to parse the payload anyway.
If you only received this message:
-
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
-
<env:Header>
-
<n:alertcontrol xmlns:n="http://example.org/alertcontrol">
-
<n:priority>1</n:priority>
-
<n:expires>2001-06-22T14:00:00-05:00</n:expires>
-
</n:alertcontrol>
-
</env:Header>
-
<env:Body>
-
<m:alert xmlns:m="http://example.org/alert">
-
<m:msg>Pick up Mary at school at 2pm</m:msg>
-
</m:alert>
Could you still get to the msg element? Sure, using a SAX-style parser. A DOM parser might choke on it. But you might not really care about the information in the header. Heck, you could just use a text-stream reader. What about instead of the XML fragment above all you got was this.
-
msg=Pick Up Mary at school at 2pm
Heck, you don't even need a fancy parser to handle that. Just take everything right of the "=" and off you go.
Is my point that SOAP/XML-RPC/WS-* suck? No, but you should voluntarily pay the message tax. Don't assume that just because you are using a "web service" that you need to use a known messaging scheme.
Say Dave
How about making sure your browser works with their websites instead of the other way around?
Dave Massy's WebLog : More Mix
In the IE7 compatibility lab we discussed a variety of issues with attendees helping make sure their websites work on the new browser.
update: After investigating the actual lab, it looks like the point of the lab was to show developers how to remove the IE specific markup and code from their site and make it more standards compliant so it will work with IE 7. Good Job!
Old computer viruses
I was reading a forum thread today about the Vista release slip and Larry Osterman mentioned working on NT 3.1. Someone in the forum said it was the most stable OS they'd ever used. I said DOS 5 was the most stable. Probably the most secure, it didn't ship with a networking stack! You had to download viruses and run them manually. But I remember two of my favorite computer viruses from way, way back.
Cookie Monster: This one was pretty harmless. It would occasionally pop up a message on a users terminal and say "I want a cookie!". If the user typed in "cookie", it went away for a while. If they typed in "Oreo", it went away for good. The link is to the source code for the original
Ambulance: Randomly, a graphical ambulance would scroll across the bottom of the users screen and a siren would play over the speaker.
We are all Mort
Every now and then I see blog entries decrying the existence of "Mort", the ubiquitous inexperienced programmers who's code we always have to fix. They complain about how language X is getting dumber to accommodate "Mort" or that their favorite IDE has some new feature that makes it easier for "Mort" to write bad code. I snicker when I read these posts because they don't get it. The entire POINT of writing code is to abstract away the difficulty that is inherent in using computers. Remember, at the core "Mort" is just another user. I know that if there was a way to drag and drop icons into a designer and have it output good code, I'd use it. Otherwise, we might as well be flipping switches on a console.
Some developers don't want to design the perfect, scalable architecture. They just want to solve a problem.
Why are programming languages all based on English?
Jeff Atwood has a nice rant about case sensitivity in programming languages. During the course of the discussion, I pointed out that all programming languages are based on English. (I was wrong). Jeff then asked.
So why aren't programming languages localized, if everything else is (the os, the applications, the web)? What's so special about a programming language that makes it magically exempt from localization entirely?
Which is a good question. It's one I brought up at the Seattle Code Camp during my presentation. Wouldn't a multi-byte language like Chinese or Arabic provide you with a lot more symbols when constructing your language?



