下位展開をセクションにした理由。
ページだけのネストでなければ応用しづらいので、これらを解決してページのネストにする。

  1. ページのネストではいけない理由
    1. ページは豪華すぎる
    2. いろいろな見解と権限が1ページに混在して閲覧者にとって分かりにくくなる？編集者にとっては？
    3. 下位を消すとき参照と本文の両方を消さないといけない？見出しの順序はどう保存するか。forkしても壊れない？
    4. ページ属性の継承に問題はない？
    5. ページ裏の属性自動変更に問題はない？
    6. forkするとそれより下位を編集する手間が増えたりしない？
  2. 下位展開はまとめ機能
  3. 閲覧不可ページの子が閲覧可能だと

ページのネストではいけない理由 † Edit

→すべて解決できそう。

ページは豪華すぎる † Edit

ページ属性、履歴などがあるが、一つのページとするには余分。
→使うときに分かりやすければいい。分かりにくければ特定のページでだけ使うようにする。

いろいろな見解と権限が1ページに混在して閲覧者にとって分かりにくくなる？編集者にとっては？ † Edit

→見解は横スクロールなどですぐ見られるように。閲覧者の権限は表示/非表示なので気付かれない。編集者の権限は設定（運用の問題）で分かりやすく。デフォルトでは簡素なのでそれ以上複雑にしなければいいだけ。

1ページにまとまるとできなくなる操作は、まとめないビュー（詳細表示といわれるもの）で行なう。
「詳細表示」よりは「フォーカスする」とか「ここだけ表示」とか「（ここを）いろいろと操作」としたほうが分かりやすい。

下位を消すとき参照と本文の両方を消さないといけない？見出しの順序はどう保存するか。forkしても壊れない？ † Edit

→埋め込み記法で実装するなら両方。

そうでないなら見出しの順序が大事。
→できればそうでないほうで。ページ間のつながりは無いほうがいい。
どう順序を記録するか？

forkした版同士につながりはない。fork元と同じつながり。

ページ属性の継承に問題はない？ † Edit

→下位展開はビュー上のもの。属性とは別問題。

ページ裏の属性自動変更に問題はない？ † Edit

→下位展開はビュー上のもの。属性とは別問題。

forkするとそれより下位を編集する手間が増えたりしない？ † Edit

→下位は参照だけの浅いコピーで増えたように見せるだけ。そのコピーをforkすることは可能。

下位展開はまとめ機能 † Edit

順不同ページ名によって、基準ページの指定は下位ページ名の一部ということになる。
換言すればページ名検索の検索語を指定するようなもの。表示順序がドキュメント側で定義されている検索結果。

つまり個々のページを一覧化するまとめ機能。

閲覧不可ページの子が閲覧可能だと † Edit

閲覧不可能の子は経路がないけどアクセス可能
URLを知っている人に公開（消極的公開）ということ