このエンコーディングを必要としないのに<、XML 属性値でエンコードする必要があるのはなぜですか?>
明らかに「仕様書にそう書いてあるから」です..
..しかし、このコンテキストでエスケープする必要がない場合、解析の観点から、この制限が存在する理由について、単純で実用的な例または理由を探しています。>
私は何も考えられませんが、元の理論的根拠を判断しようとせずに（文書化されていない限り）、この制限が削除する解析/構文の複雑さ、またはこの制限を追加すると何が可能になるかを確認したいと思います-それは使用されていますか/ 「探す」のに役立つ？属性値とテキスト コンテンツの解析の統合を可能にしますか? 他の？
それは自己同期的なものである可能性があります。タグスターターとしての役割を除いて、XMLドキュメントの内部で「<」が発生しないことを保証する場合は、ドキュメントの途中から開始し、「<」が表示されるまで文字をスキップしてから、タグの先頭にいることを確認して、解析を開始します。素朴なことに、これはそれほど有用ではないようです—真ん中からXMLを解析することはあまり意味がありません—しかし、おそらくそれはエラー回復に影響を及ぼします。「<」が保護されている限り、同じように「>」について心配する理由はありません。
「なぜ」の質問に答えるには、次の 2 つの方法があります。
(a) このルールを持つことによって役立つ目的を思いつきますか?
(b) 歴史的事実として、実際にその問題が正式な決定に持ち込まれた場合、なぜ作業部会のメンバーがそのような方法で投票したか知っていますか?
歴史的アプローチ (b) は非常に困難です。決定が下された会議に出席していた人でさえ、委員会がその方法を決定した理由を理解するのが難しい場合があり、議事録からそれを解決することは通常不可能です. 午後遅くだったかもしれません。彼らは、変更を提案していた人にいらいらしたかもしれません。
ただし、通常、XML 仕様の奇妙さは SGML の起源にまでさかのぼることができます。XML ワーキング グループは、SGML で許可されていないものは XML で許可されないようにすることを切望しており、SGML は構文上の柔軟性の結果としてあらゆる種類の制限を課しました。私は SGML の専門家ではないので、これ以上正確なことは言えませんが、これが説明であると 90% 確信しています。