人間可読属性値

[4] SGML や XML は属性値を文字列としており、 (応用依存ではない形の) 複雑な構造を記述できません。 人間可読属性値は悪い習慣といわれていました。

[5] 人間可読属性値は避けて (子要素を使って) 要素の内容とするべきといわれていました。

[6] ところがそれでは著者にとっても処理するプログラムにとっても扱いにくさが極端に増すので、 あまり好まれませんでした。

[8] (HTML でいう) ruby や bdo のような国際化に関係する要素を属性値で記述できないため、 国際化の専門家を称する人々が特に主張していました。

[11] 人間可読属性値を避けるべきという考え方自体が、 HTML の ruby 要素に至る機能開発の中で生まれてきたと思われます。 (ruby 要素の当初の設計は、 専用の要素ではなく振り仮名を属性に記述するというものでした。)

[9] Atom 1.0 の Language-Sensitive はそのような時代の産物で、 人間可読な内容をすべて要素の内容として記述しています。 Atom は基本的に属性を使わず子要素で親要素を説明する形で統一されて設計されているので、 人間可読属性値を避ける方針がうまくなじんでいます。

[10] HTML は人間可読属性値を避けるべきという考え方が生まれる前に作られた構造が多く、 人間可読属性値がよく使われます。 先例を踏襲するということで新たに作られたものもあります。 後に翻訳可能属性といわれるようになりました。

[12] HTML で最も象徴的なのが title 属性です。 要素についての追加情報を記述できるものです。 HTML では文書のメインの内容というべきテキストが要素の内容に記述される設計なので、 文書の主たる表示とは別に表示されるべき title の文字列が属性値でなく子要素で記述されるとなると、 多少の違和感があります。

[13] SVG は title 属性に相当するものを title 子要素としています。 SVG では要素の内容は親要素を補足する子要素になることが多いので、 title が子要素になっていてもあまり違和感がありません。 ただし HTML との整合性を欠いているという欠点 (言語設計の美しさだけでなく、実装の共通化にも支障があり、現に SVG でも誤って title 属性を認識する実装があった。) がある上、 SVG文書全体の題名の title 要素と (若干機能性が異なるにも関わらず) 統合してしまっているのもやや問題です。

[14] こうした実例を見ていくと、 「データ構造的な言語」 では人間可読属性値を避ける設計が馴染むのに対し、 「文章的な言語」 ではそうでもないように思われます。 人間可読なデータの非線形的混合を記述しづらいのは SGML の設計の限界かもしれません。