Joel on Martian Headsets (standards)

I'm generally not a big fan of the "link dump" style blog.  However, the latest post on Joel On Software regarding web standards was too good not to share.

Some choice quotes...

Regarding "working around" problems in an implementation (bolded by me):

And eventually some tedious bore writes a lengthy article on her blog explaining a trick you can use to make Qxyzrhjjjjukltk 5.0 behave just like FireQx 3.0 through taking advantage of a bug in Qxyzrhjjjjukltk 5.0 in which you trick Qxyzrhjjjjukltk into deciding that it’s raining when it’s snowing by melting a little bit of the snow, and it’s ridiculous, but everyone does it, because they have to solve the hasLayout incompatibility. Then the Qxyzrhjjjjukltk team fixes that bug in 6.0, and you’re screwed again, and you have to go find some new bug to exploit to make your windshield-wiper-equipped headphone work with either device.

Regarding language used in a lot of standards documents:

Those documents are super confusing. The specs are full of statements like “If a sibling block box (that does not float and is not absolutely positioned) follows the run-in box, the run-in box becomes the first inline box of the block box. A run-in cannot run in to a block that already starts with a run-in or that itself is a run-in.” Whenever I read things like that, I wonder how anyone correctly conforms to the spec.

That one I have a lot of sympathy for.  In a previous life, I worked as a tester on the XML datatype implementation in SQL Server 2005.  There was a quite a bit of time spent going through various W3C specs on XQuery, XPath, and XSD.  IMO, the specs are insane.  In some cases they go into excruciating detail about the internal semantics of a particular operation -- as an example the XQuery 1.0 Formal Semantics spec says that path expressions should have the same semantics as (ie, they should normalize to) the XQuery for statement.  In other words, an expression like /foo/bar/baz should look like a set of nested loops.  Unfortunately, it also defines that the normalization process of each sub-expression (a relative path expression) should return the results in document order. There are a couple of problems here (directly related to SQL Server's implementation).  First of all, SQL Server uses static typing, and for breaks static typing because it implies zero-or-many cardinality.  This breaks functions which require a singleton unless you really want to put (/foo/baz)[1] around everything (note if you are using untyped xml, you need to do this anyways -- sorry).  AFAIK, SQL Server is not conformant in this regard (it has been a while though, so maybe I am missing something).  The other big hangup I have is that the implication of document ordering at each step in the path seems to preclude the potential for a more global optimization where you defer sorting until the very last step.

One of the major takeaways that I had from Joel's post was that it is incredibly difficult to implement against a standard when that standard actually has no implementation.  I don't know if it is possible to get around this.  Some standards are amazingly complex -- I can't imagine there being a reference implementation which is so robust that it becomes the standard.  Maybe if you go into the whole standards argument saying that the implementation _is_ the standard then you are better off, but I suppose that has its own problems as well.