nextLinkとpageElementの推定

Pagerization version 0.2.2 - ?D of K

アルゴリズムどうなってるのかなーと思ってみた。nextLinkはOperaのFast Forward方式にタグのattributeを見たりするのも加えたかんじで、pageElementはnextLinkとのHTMLソースのdiffをとってる。ソースのdiffなのは以外だった。ソースのdiffからどうやってXPathを作ってるのか知りたい。

自分がHTMLのドキュメントから繰り返し部分をみつけるでpageElementの推測(というよりはLDRizeのparagraphの推測を目標にしている)に使ってる方法は、nextLink(は手動で選択する)とのXMLドキュメントの差分をとって、中に含まれているテキストの量を考慮に入れつつ、差分が最も多いツリー上のノードをみつけてその子要素にうまくマッチするようなXPathを作っている。このアプローチはXMLドキュメントの比較処理が重たくて、自動で実行するのはちょっと厳しかった(でもある程度の精度が出せるならextensionにして別スレッドで動かすとかすればいいと思う)。


作ったときにpageElementは結構いけるとかんじた。自分が気付いたことを書いときます。

pageElementじゃないところにたくさんの差分を含んでいるものがある

ディスカッション - mozilla.dev.security | Google グループみたいに、pageElementの右側のところに、すごく差分を含んでいたりするものがあって、ページの半分以上がサイドバーなニュースサイトで、かつそれがランダムに出たりするものだとそっちにまっちしちゃいます。
TechCrunchの右側swickiって書いてある部分も、ランダムで出ていて、タグのレベルで見ると毎回pageElementよりも差分がある状態になっています。でもこれはテキストの量で見ると解決でした。たいていはpageElementのテキスト量の差分のほうが多いです。

重要な部分が大きくなるように作ってあるのfubaさんのコメントも参考になると思います。
あと、面積じゃなくて(面積は画像が入ってると大きく変わるというのを教えてもらいました)、要素の幅がすごく役に立つ感じがしました。まともなレイアウトがされているページであれば、pageElementが一番大きな横幅を持っています。

nextLinkは手動でいい気がする

けっきょく画像で<img src="r16.gif" />みたいなのがnextLinkだったりして、そうするとどうがんばっても推定できない。XUL Apps > Rewind/Fastforward Buttons - outsider reflexのようにURLがどうなっているかから推測するアプローチでどれくらいいけるか知らないんだけど、はじめの1回だけ次のページのリンクをクリックするのはそんなストレスになるようなことじゃないので、難しいnextLink
を推測するのはとりあえずあきらめてpageElementの推測精度を上げるほうを優先でやってもいいんじゃないかなーと思います。
人間がやったほうがかんたんなことは人間が、人間がやるのはめんどくさいことはキカイが、っていうことが可能なブラウザの上のことだから、ニンゲンを利用しない手はないと思います。


というわけでちょう応援してるのでがんばれー!