真の護身が完成すると、危険に気づくまでもなく、危険に近づくことができなくなる、という（『グラップラー刃牙』）。
プログラマも護身する。
護身ができているプログラマは、危険なツールや規格やフレームワークを、その存在に気づくまでもなく回避する。
過去の例を挙げよう。RDBMSにMySQLを採用して、4.1の文字化け問題を踏んでしまったプログラマは、護身ができていなかった。護身ができていれば当然PostgreSQLを使っていただろう。
また、現在の例を挙げれば、PHPを使うプログラマは護身ができていない。護身ができていれば当然PythonかRubyを使うだろう。
これらの護身は、なにも超能力ではなく、事実にもとづく総合的な判断だ。
たとえば、日本人の開発者はMySQLには少なく（おそらく存在しなかった）、PostgreSQLには多い。となるとMySQLがいずれ日本語関係で問題を起こすかもしれないと予想できる。また、MySQLのパフォーマンス特性も、素人向けマーケティングの臭みが鼻について食えたものではなかった。「トランザクションなしで参照だけ速い」というパフォーマンス特性がなにを意味するか、わからない人は素人だ。
こうした判断を正確に下すには、時間的・分野的に広範な知識が要る。そして、その判断の中身を詳しく説明するのは、ほとんど不可能だ。
MySQLのように、普及したあとで明白にコケて災厄を引き起こした場合は、その理由を説明できる。しかし、このような華々しい災厄は例外に属するし、その説明も遡及的なものになる。たいていはXLinkやRELAX NGのように、単に普及せず、なにも起こらない。この場合は説明が難しい。
さて本題である。
XQuery 1.0が勧告になった。2001年のワーキングドラフトから5年1ヶ月、やっと勧告にたどりついた。
というわけで読者諸氏にご忠告する。XQuery 1.0には近づかないほうがいい。
上記のとおり理由を説明するのは難しいが、ひとつだけ挙げるなら、XQuery 1.0はいろいろな点でXLink 1.0に似ている。XMLの専門家からは長らく期待されながら、なかなか勧告にたどりつけなかった点。勧告にたどりついた時にも、利益を産むソフトウェアに使われている気配がない点。
2012年にこのエントリをご覧の読者諸氏は、いかがお思いだろうか。