Catyの最初からの方針として、「URLの書き換えやマッピングは一切しない」というのがあります。どうしてかと言うと、書き換え/マッピングをすると、Webサイトのコンテンツとその配置が、設定ファイル/プログラムロジック/データベースなどのなかに隠れてしまって、プログラマ以外(ときにプログラマでも)サイトの構造が把握できなくなるからです。もちろん、その代償に柔軟性が失われます。ここらへんはトレードオフなんで、Catyは柔軟性より把握容易性を採ったということです。
そういう事情なんで、CGIスクリプトも含めて外部からアクセス可能なWebコンテンツは必ず、ファイルシステム(mafs;最小抽象ファイルシステム)上のファイルとして実在します。(ファイルシステム上にあっても外部から見えないファイルはあります。)ファイルシステム内をたどって調べれば、Webサイトの全コンテンツを確実に列挙できます。
ファイルシステムにおけるディレクトリ階層構造がそのままURLに反映されるので、物理的フォルダーの包含(containment)構造とURLの接頭辞順序構造は一致しています。しかし、サイトの構造といえば、ハイパーリンクによるグラフ構造のほうがより重要でしょう。すべてのコンテンツが実体として存在しているので、サイトのリンク構造を有向グラフとして抽出することもできます。ただし、いくつかの問題があります。
Catyのサイトは、プログラム(コマンド)やストレージ(リソースファイルシステム、JSONストレージ)をたくさん含んでいても、サイトの構造は静的サイトと変わりません。テンプレート構文は、HTML文書構造を破壊することはないので、テンプレートを解析してハイパーリンクを抜き出すことができます。しかし、<a href="{$topPage}">
とか書かれるとリンク先が不明になります。これがまず問題です。
さらに、CatyサイトにはHTML以外の形式の文書もあります。例えば、wiki記法で書かれたファイルがそのまま置かれていたりします。wikiの内容を解析するには、wikiのパーザーが必要になります。コンテンツのファイル形式(フォーマット)ごとに、内容を解析するプログラムが必要になるのです。
以上に指摘した問題はあるのですが、サイト内の全てのコンテンツを列挙し解析すれば、各コンテンツごとに次のようなサマリー情報が得られるでしょう。
- filePath -- サイト内のファイル名
- title -- 題名
- description -- 短い説明
- outerLinks -- サイトの外部に向かうリンクの集合
- innerLinks -- サイト内の他のコンテンツを指すリンクの集合
これらの情報を保持したノードを考え、innerLinksをノード間の矢印(有向グラフの辺)と考えれば、有向グラフを描けます。
一旦有向グラフが出来てしまえば、ノード間の可達性、ハブノードの存在、ノード間の経路距離などを判定/算出できます。入次数/出次数(in-degree/out-degree)などから何か計量的な指標が得られるかも知れません。特定のノード(Webコンテンツ)から距離nの近傍(距離がn以内のノードの集まり)を観察したり、可能な経路をすべて列挙してみることで、サイトに関する知見が得られるかも知れません。
「知れません」と書いたのは、実際にやってみないと有効性が分からないからです。もちろん、僕は有効だろうと思ってますがね。URLが、対応表を引くキーとかプログラムを起動するトリガーだったりすると、サイト内全コンテツを列挙して静的解析を遂行するのはかなり困難だと思います。「静的サイトと同じ作りにする」に拘っているCatyだから実行可能なタスクだと思えるので、やってみる価値はあります。