* プロトコル要素の人間可読性

[1] [[プロトコル要素]]等には主として[[人間可読]]なものとそうでないものがあります。

[2] その[[人間可読]]な度合いや[[言語]]等に関わる操作の適用可能性の程度にも色々なレベルがあり、
各種仕様でいろいろな概念が定義されています。

[FIG(middle list)[ [7] [[人間可読]]な[[プロトコル要素]]を表す概念
- [[Language-Sensitive]]
- [[ローカル化可能文字列]]
- [[翻訳可能属性]]
- [[directionality-capable attribute]]
]FIG]

[15] 
[[引数 (HTTP)]] では[[人間可読なテキスト]]の構文を規定する仕様に対する要求があります。

** 人間可読属性値

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

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

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

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

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

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


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

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

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

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






* 関連

[3] [[人間可読]]と[[機械可読]]とは必ずしも[[対義語]]ではありません。

* メモ