邪悪なマークアップを解説する

面白いので何がマズイのかをついでに解説してみる。

<寄せ書き>
 <田中>元気で行ってこい。</田中>
 <ミヨ子>おみやげ、忘れないでねぇ</ミヨ子>
 <!-- ... -->
</寄せ書き>

これは凶悪な構文である。スキーマの担当者は書き込む人が増えるたびにスキーマを更新することになり、頭を抱えるだろう。彼（彼女）の心を平穏に保ちたいのならば、次のように書き直すことが推奨される。

<寄せ書き>
    <メッセージ by="田中">元気で行ってこい。</メッセージ>
    <メッセージ by="ミヨ子">おみやげ、忘れないでねぇ</メッセージ>
</寄せ書き>
<members>田中幸秀<and/>大垣美代子<and/><!-- ... --></members>

これは比較的問題の無い構文だといえる。XPath式の場合members/text()[n]と簡単にアクセスできる。DOMによる操作も順番にappendChild()すれば問題ないだろう。

ただし、メンバー名が混合タイプになると途端に破綻するため、十分な注意が必要である。今後の拡張性を考慮するならば、次のように書き直すべきである。分かりやすいように一部を混合タイプにしてある。

<members>
    <person>田中幸秀</person>
    <person><lastName>大垣</lastName><firstName>美代子</firstName></person>
</members>
<価格><税込み/>1280<円/></価格>

これもそれほど問題は無いが、混合内容のテキストをパースするのはやや面倒である上、やはり以後の拡張に危険が伴う。できれば次のように修正したい。

<価格 税="込み" 単位="円">1280</価格>

文脈によっては価格自体も属性にしてしまうほうが好ましい場合もあるだろう。

<p>彼のホームページ<spot id="fn1"/>は、...
   ...
</p>
        <footnote target="fn1">「Webサイト」と言うべきかもしれない。</footnote>

これもまた、それほど問題のある構文とはいえない。ただし、この例では「脚注」が何に対して関連付けられているかを判断するのは困難である。できることならば脚注の対象を内容とした要素にすべきである。

<p>彼の<spot id="fn1">ホームページ</spot>は、...
   ...
</p>
    <footnote target="fn1">「Webサイト」と言うべきかもしれない。</footnote>
<rangeStart name="a"/> ...<rangeStart name="b"/> ...<rangeEnd start="a"/>
...<rangeEnd start="b"/>

これはすばらしいマークアップである。この先進性を認めることができればXMLの新たな境地に達することが可能であろう。これはもはやXMLではなく、それ以外の何かに進化しているといっても良い。まさにXMLへの新たな挑戦と捉えるべきだ

このマークアップは余りにも斬新であり、革命的であり、斬新であるため、より良いXMLに書き換えることは不可能である。

（少しまじめな話をすると、実際にオーバーラップが必要な場面においてXMLは大きな制限を持っている。どうしても必要ならばこのような構文を使わざるを得ないだろう）

<chapter id="hist"><title>歴史</title>
 この章では、我が鷹巣大山村の歴史について述べる。
 <section><title>神話時代</title>
  <p>....
  </p>
  ...
 </section>
 ...
 </chapter>

この問題はXHTMLにも存在する。よく発生するのはdd要素やli要素であろう。XMLによく馴染んだ人間は、テキストが他のブロック要素（この概念はXHTML独特のものだが、文章系XML構文ではしばしば同様の分類を見ることができる）の兄弟にあると落ち着かない気分になるものである。これは、テキストノードの処理には高い集中力と技術的困難が伴うことを知っているからである。

この例ではすべてのテキストノードをp要素で括るべきだと思われる。

<chapter id="hist"><title>歴史</title>
 <p>この章では、我が鷹巣大山村の歴史について述べる。</p>
 <section><title>神話時代</title>
  <p>....
  </p>
  ...
 </section>
 ...
 </chapter>

以上のような悪いXML構文をまともな技術者が考えるとは想像しづらいが、HTMLの混乱を見る限りあながち有り得ないとは言い切れない。XMLのフォーマットを自作する場合は要求の分析や将来の拡張性に関する検証を十分に行うことが重要であると考えられる。