Race plays a big part in which candidate voters support?

Duh.

It's a shame that racism is still so rampant in some sections of the U.S. population. And even more of a shame that folks don't know how ignorant it makes you sound when you are so blatant and admitting of it.

KXSS (Keep XML Simple, Stupid)

I just ran across a post about XML on Jeff Atwood's always-wonderful Coding Horror blog. A bit of a critical post, but thankfully, not entirely so. And in fact, he sums everything up nicely at the end:

I don't necessarily think XML sucks, but the mindless, blanket application of XML as a dessert topping and a floor wax certainly does. Like all tools, it's a question of how you use it. Please think twice before subjecting yourself, your fellow programmers, and your users to the XML angle bracket tax. Again.

Now I consider myself one of the world's biggest XML (and by extension, XSLT) proponents. I just love it, and I love all of what it brings to the table. Yes, there are some drawbacks to using it, and even more to using it incorrectly or, rather, using it in a way that is not wise.

As I see it, the biggest strength of XML can also be its biggest weakness, depending on who is wielding the XML and even more so, who is wielding the design of a 'specification' to use XML, it can be overly complex and even nigh unreadable. (I actually disagree with Jeff's claim that XML was never meant to be human-readable; this was one of the big selling points of XML - moving away from unstructured and messy flat files of all kinds and moving them to XML, with its human-readable and sensible tag names and enforced structure.)

Here's an example: the SOAP folks, who had their hearts and minds in the right place, but went a little overboard in their specification design phase. This is where I absolutely agree with Jeff. Compare his SOAP sample:


<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP-ENV:Body>
    <m:GetLastTradePrice xmlns:m="Some-URI">
      <symbol>DIS</symbol>
    </m:GetLastTradePrice>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>


...with an 'alternative' which ends up being a bit simpler, and which conveys just about the same information:


<Request>
  <Method name="GetLastTradePrice">
    <Parameter name="symbol">DIS</Parameter>
  </Method>
</Request>


Admittedly, we're ignoring encoding and also namespaces in this simplification (which in my experience are usually the cause of a most of the complexity and heartache when dealing with XML), but the point here is that the onus is largely on the individual (or [shudder] committee) designing the spec for the XML to Keep Things Simple (TM).

Of course, REST proponents (of which I am certainly one these days) will throw this even more simple equivalent at us:


http://[someurl.com]/request/getlasttradeprice?symbol=DIS


...and I don't blame them. Like Jeff says: these technologies are all just tools in your toolbox...it's up to you to decide which of those tools you will use in any given situation...and how you will use that tool.

lolSofia