photo author:snj14 email: web:http://white.s151.xrea.com/blog/ home:Shizuoka,Japan about:blog,my outputs

LDRize専用のmicroformatsについて

2008/06/09 (since: 2008/01/31 )

先に結論

LDRize専用のオレオレフォーマット案には反対です.その理由を書きます.ついでに今後の展望について書くつもりでしたが,疲れたので途中まで.

今までの話の流れ

- 内部向けのサイトなので,公にSITEINFOを書きたくない - 「v」「o」で開くようなリンクはなく,「j」「k」のスクロール操作だけを利用したい ちょっと特殊なケースですね.

実は,これは今まで見えにくかっただけで,LDRizeの一番の利点を生かしたケースじゃないかと思っています.ちょっとだけTumblrに書いたやつちょっとだけTwitterに書いたやつ1ちょっとだけTwitterに書いたやつ2以外はまだオンラインにあげてないので,詳しくはまた今度書きますが(多分),LDRizeの利点は以下の3つだと考えています.

じゃあ,今回のケースのようなサイトでLDRizeの「j」「k」スクロールだけを利用したいときにはどうすればいいでしょうか. オレオレフォーマットにはなりますが,SITEINFOに domain: 'microformats', paragraph: '//*[contains(concat(" ",@class," "), " ldrize-paragraph ")]' のような記述を追加し,サイト側のマークアップで対応するってのは現時点ではアリかなと思っています. 皆さん,どう思われますか.

と言われて,あとで書く!と思いながら随分時間が経ってしまいました.すいません.

まとめ

用途を定義したmicroformatsが駄目な理由

AutoPagerizeのmicroformatsは,完全にAutoPagerize用です. 一方でLDRizeのカバーしている microformatsは,LDRizeのためのものではないので, LDRizeを動作させるためにマークアップすることが意味的に正しいとは限らないのですね.

引用部にもありますが,LDRizeが利用するmicroformatsはLDRize専用のものではありません.そもそもmicroformatsは,HTMLの構造をある程度統一することで,意味を持ったデータをプログラムから取得するものです.用途に対してmicroformatsを定義すると「1つの用途」にしか用いることができませんが,構造に対してmicroformatsを定義すると「複数の用途」に用いることができます.前者で複数の用途に用いてもいいのですが,もともと「1つの用途」のためのマークアップなので,変更があるかもしれません.変更された時に,そのmicroformatsを利用している別のプログラムもそのまま利用し続けていいと保証できるのでしょうか.

具体例を挙げます.

autopagerize_page_element は,AutoPagerize用のmicroformats(?)です.class="autopagerize_page_element"で指定された部分をclass="autopagerize_insert_before"で指定された部分の直前に挿入します.なので,autopagerize_page_elementは だいたいページのコンテンツの部分 となります.ですがautopagerize_page_elementという名称は 用途 を表しており,構造 を表しているわけではないので,ページのコンテンツの部分でない可能性もあります.

ここで,ページのコンテンツをスクレイピングしてページの要約を作るようなスクリプトが ページのコンテンツの部分 を欲しいとします.このスクリプトはautopagerize_page_elementを利用しても大丈夫でしょうか.もしHTMLが変更されてautopagerize_page_elementに広告が入り,メタデータ(時間,タグ,コメント etc)が入り,AutoPagerizeに利用するには問題ないがページのコンテンツの部分でない という状況になったら精度に問題が生じるのではないでしょうか.そう考えると,autopagerize_page_elementをAutoPagerize以外の用途に用いるのは避けたほうが良いでしょう.

では,このスクリプトはまた別に専用のmicroformatsを作るべきでしょうか?もし,autopagerize_page_elementのような用途に対するmicroforamtsではなく,ページのコンテンツの部分という構造に対するmicroformatsが定義されていればどうでしょうか?

話しは反れますが,CSSのお勉強系のサイトに,HTMLのクラス属性の設計で 構造 でなく 用途 を限定してしまい,とても恥ずかしいことになってる例の代表がよく載っていますよね. class="red" とか.

wikipediaにも マイクロフォーマットには用途ごとに様々なものがある とか書いてあるのはどうにかしたほうが良いと思う.

まとめ

Microformatsの問題点

ついでにmicroformatsの問題点について.

microformatsはお手軽な分,全然正確ではありません.もしautopagerize_page_elementがcontentsくらい短くなったら誤爆する可能性があります.その場しのぎの解決策としてはAutoPagerizeみたいに接頭辞をつけるか,hAtomみたいに親要素にhfeedをつける といった方法があります.kuさんの記事にもありますが,これはmicroformatsの限界なのでしょう.

microformats以外の方法がないかと探してみたところ,RDFaというものがありました.これはmicroformatsみたいに決まったクラスを指定したりしますが,XML名前空間を指定したりする必要があります.名前空間の指定があるので正確ですが,どこからどこまでがこの名前空間なのかという適用範囲を理解する必要があります.また,microformatsに比べてだいぶXHTMLが複雑になるので,美しくありません.microformatsでさえ面倒がってやってくれないのに,さらに数段階面倒なことはさせるのは非現実的です.

まとめ

SITEINFOの問題点

ついでにSITEINFOの問題点について.

少し前にAutoPagerizeのSITEINFOに「exampleUrlをつけるように」というお達しがでました.一度作成したSITEINFOがHTMLの変更によって無効化されることがあるため, 現在は有効なのか無効なのかの判断を機械的にできるようにするためです.それでも,その判断は別のスクリプトで行う必要があり,無効になっていた場合にwikiから外すのも人力で行う必要があります.

また,AutoPagerizeのデータを再利用する話しも出ています。

他のユーザースクリプトなりアドオンなりで前のページへのリンクの情報を使うような物もあるかもしれないし、 ということでSiteInfoには前のページへのリンクの検出ルール(prevLink)も含めてもらえると主に僕が嬉しいです。

仮に,prevLinkを追加したとしましょう.そうなると「この値も入れて!」って言う人がきっと他にも出てきます.となると, どんな名前がどんな意味を持っているのか をプログラム間で共通のものにする必要があるでしょう.ある人がmainContentという名前を追加して,他の人がsiteContentという名前を追加したけど意味は同じ,という状態になると,とてももったいないことになります.さらに前述したようなHTMLの変更が加わると,誰が変更するのか,全部変更しなければならないのか,何を表しているかも分からない値の変更はどうするのか,分かる範囲で修正した場合はどれが未変更の値なのかをどうやって区別するのか,といった問題も発生します.

まとめ

Microformatsの先へ

ところで,GRDDLというものが少し前に勧告されています.これはmicroformatsを利用してRDFを抽出するために,head内にlink要素としてXSLT(XSLTじゃなくても良いけど普通はXSLTみたい)を指定するものです.RDFを抽出するXSLT側に,名前空間の指定などの面倒なことを隠蔽できるので,HTML側は普通にmicroformats的なマークアップをすれば良いのです.そして,headタグのprofile属性にちょろっと書き足してlink要素を書き足すだけです.microformats的な,と書いたのは,microformats.orgで決められたmicroformatsでなくても,XSLTさえ書けばRDFを抽出できるためです.

なのでGRDDLでRDFを抽出することは,microformatsの手軽さを保ったまま正確さを獲得できます.正確さといっても,HTMLを書いた人によって保証されるだけですが.

まとめ


つかれたのでここまで.続きはまた今度.