2010-02-19
「第3回 Webkit/HTML5勉強会」に行ってきました(後編)
Microformat と Microdata の紹介 by Oli さん(http://oli.jp/)
はじめに
HTML に(ヒューマンリーダブル、マシンリーダブル問わず)メタデータを付加する方法はいくつもあるわけですが、クリエータベースでボトムアップに使われ始めたものの代表が Microformat です。
ここにチートシートがありまして、一見すると「ぎょっ」とするほどあります。
Microformat の問題と RDFa
一言で言えば、 Microformat → RDFa → Microdata 。 HTML5 は Microdata でがんばっていこう!
とまぁ、色々仰っていたのですが、Microformat は問題だらけで、ボトムアップすぎて HTML の仕様として入っていないこと、実装方法がばらばらになってしまって種類が多すぎること、そのためかツールや UA の実装が揃ってこなかったことがあると。あと、ボキャブラリをマシンリーダブルに新規作成することができず、コミュニティによる追加を待たなければならないこと。属性値のフォーマッティングなどを全世界共通のマシンリーダブルなものとしてしっかり策定できなかったこと。オリさん曰く「Microformat は "stop-gap"(応急処置)な技術である」ということ。
対して、W3C が XHTML に対する仕様として策定を進めていた RDFa は、コンピュータリーダブルかつボキャブラリ定義も一つのリソースとして URI を割り当て、かつボキャブラリの属性値のスキーマすら一リソースになるなど意欲的ではあるが、 rigor (厳格・厳密)すぎることと、要するに時代は XHTML2 ではなく HTML5 を選択してしまったので、 HTML5 にはフィットしないよね。という状況になってしまった。
そこで Microdata
そこで登場したのが Microdata で、 WHATWG によって HTML5 の仕様の一部として含められており、かつ RDFa よりは実装しやすく、ボキャブラリも作者が定義できるなど自由度もあり、 Microformat と RDFa の反省をそれぞれ活かしたものになっているということ。
http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html
プレゼンの以後は、時間がおしていたこともあり巻きで Microdata の実装紹介でした。この辺はスペック通り。
これからは Microdata
になるだろう。ということです。 HTML5 がこのままデファクトになればそうでしょうね。問題点は、
- brand new(新しすぎる)
- almost no tools(ほとんどツールがない)
- almost no usage(ほとんど使い道がない)
- it's not RDFa(RDFa ではない)
ということだそうです by オリさん。
感想
私個人の考えとしては、現状、 HTML へのメタデータ付加は SEO 対策としても弱く、実効性にかなり乏しい。実効性があると言えるのは、 FOAF/XFN くらいではないだろうか。先進性を取って進めるのも良いが、業務として行う場合、ただの無駄なコストになる場合が多いと考えられる(特に更新作業)。ボランタリーベースになるだろうと思われる。 FOAF/XFN のように、Google がなんらかの対応を公式に発表した時点からメタデータ実装を考えても何ら問題ないのではないか。多少後ろ向きではありますが、そのように考えます。メタデータをいくら付けたって、それを読んでくれる人がいなければ作者も更新しなくなるし、ブログツールなどの更新ツールも対応が進まない。更新されないメタデータほど悲惨なモノはない。
と書いて「悲観的すぎるだろガンガン付けていこうぜ」と社内イントラでコメントをいただいたので補足すると、僕は「メタデータ超付けよう」派の中の「メタデータのメタデータ化は人ではなく機械がやるべき」一派です。人が「メタデータ」と意識して何かを入力するのではなく、普通に「コンテンツ」を記述している気持ちで入力すると後は機械が「メタデータ」として文書にデータを付加してくれるのが良いな!
「第3回 Webkit/HTML5勉強会」に行ってきました(前編)
概要
- HTML5 バリデータ "validator.nu" について by Mike(tm) Smith(W3C) さん
- Microformat 及び Microdata について by Oli さん(http://oli.jp/)
HTML5 バリデータ "validator.nu" について by Mike(tm) Smith(W3C) さん
はじめに
という、 HTML5 のバリデータを作っているメンバー(メインコミッターは二人だけ!)の一人、Mike さんによる直々の紹介。このバリデータのキモは一点。 DTDベースではない(SGMLベースではない) ということ。
が売りであり、高速かつ「practicalな」(Mikeさん談)バリデータを目指しているとのこと。
気づいたこと
HTML5 はそもそも DOCTYPE 宣言中に DTD の URL を記載しないなど、形骸化した DTD (ブラウザはそもそも DTD による SGML-aspect なチェックをこれまで 一切 していない)を廃していこうとする方向である。
しかし、そうなると「どう機械的に検証するのか?」という問題がある。 HTML5 の仕様は当然ながら自然言語で書かれており、機械はそれをスキーマ言語としては利用できない。また、一コーダとしても、ある属性値の取り得る形式を知るために自然言語に当たるのは骨が折れる(要するに、これまでは自然言語の仕様書読むより DTD 読んだ方が速かった)。
そこで、 validator.nu は上記の通りクリエータにとって使いやすく的確にエラーをつぶせるバリデータを目指しているということである。また同時に、Mike さんは Whatwg のメンバーでもあり、なんと、 HTML5 の自然言語版の仕様書は、この validator.nu 用の RELAX NG スキーマから起こされているという(本当!?というようなことを言っていたんだけど、確認できず!)。つまり、事実上は HTML4 までの DTD に取って代わろうとする存在と考えてもいいのかもしれない。実用上は。
多様性・多態性
validator.nu は、
を参照すると分かるとおりかなり自由度が高い。デフォルトでスキーマも複数用意されており、
- HTML5
- HTML5+ARIA
- HTML 4.01 Strict + IRI / XHTML 1.0 Strict + IRI
- HTML 4.01 Transitional + IRI / XHTML 1.0 Transitional + IRI
- HTML 4.01 Frameset + IRI / XHTML 1.0 Frameset + IRI
- XHTML5
- XHTML5+ARIA, SVG 1.1 plus MathML 2.0
- XHTML 1.0 Strict, SVG 1.1, MathML 2.0 + IRI
- XHTML 1.0 Strict, Ruby, SVG 1.1, MathML 2.0 + IRI
- XHTML Basic + IRI
- SVG 1.1 + IRI
に対して検証可能である。( IRI って国際化 URI ですよね?)
また、上記デフォルトスキーマ及び Java 検証コードがビルドスクリプト付きで提供されており、自社のサービスや納入先クライアント、対象ユーザーエージェントに合わせて属性や要素を追加したり、属性値の形式をより厳密にしたりといった検証機構のカスタマイズが可能であるというのが自慢だそうだ。それは便利だし、何しろ HTML5 のボトムアップ的な雰囲気がにじみ出ていて面白いと感じた。極論すれば、 XHTML2 は「仕様書がすべて」だったのに対し、 HTML5 は「実装がすべて」である。分かりやすい対比です。
コミッタ募集中
何しろ二人で作っているので、HTML5 の仕様変更や要素追加に合わせて
が追いついていないとのこと。 Java プログラマのコミッタ募集中とのことです。
応用例
対象ユーザーエージェントを絞る場合( "iPhone版" など)、JavaScript やサーバアプリケーションからの要件によって追加要素や追加属性、属性値のオリジナルな検証を行いたい場合も、カスタマイズして利用できることが大きい。
実際に表示した状態でのテストは Selenium がありますが、コードレベルでのチェック、つまり「テスト」にはこれが利用可能です。すばらしい!
取り急ぎ、マイクさんの前半は以上。
社内イントラでコメントいただく
補足: RELAX NG は DTD の直接の代替というよりは、W3C XML Schema を代替しようとするものだったはずです。
なるほど分かりやすい!





