■[雑記] 第十回 XML開発者の日に行ってきた。

今年も行ってきたでよ。

村田さんあいさつ

• XMLが97? 98年に勧告になって10年で10回くらい
• 今回もdeepな話でみんな楽しみにしてるでしょう。
• 昼休みにたべるところは近くに何箇所かあります。
• 発表中の突っ込み歓迎
• 2番目の発表者は面の皮が厚いのでぎったぎったにしてあげてください。

源氏物語の世界 再編集版 by 宮脇文経さん

村田さんによる紹介

• 思い入れは今回の発表の中で一番強いのでは?

元は趣味で作成していたもの。

• コンテンツの拡張をしようとして、IPAに提案した後でXMLでやろうと決めた。
  • オリジナル by 渋谷栄一教授（高千穂大学）
  • V2：XML
  • V3：XML

採択の経緯

• 元の提案はコンテンツの整備だったけど、却下された。
• PMに興味を持ってもらえて、「〜なプログラムとデータ構造」に限定し、調査費として採択してもらえた。
  • 既存コンテンツとのタイアップとか、ボランティアの活用とかの環境整備のためにお金が出た。

目標

• V1でHTMLで整備されたものがちょっとあった。
• 第三者が追加できるようにするところがV2以降の新機能
  • コミュニティの整備はまだできてないけど、仕掛けはできた。
    • 注釈を追加できる
    • 本文以外のテキストにも注釈や解説が追加できる
    • などなど

V1：HTML版の機能

• オリジナルのHTMLファイルをプログラムで変換し、アップロード（静的ファイルになる）。
  • オリジナルはほとんど生のテキスト、リンクもない。印刷したものを左右において読んでいくような使い方を想定（?）
  • V1の結果は本文、渋谷先生の訳、与謝野晶子の訳（著作権の切れてるもの）を並べて表示できる。（tableで）
  • 54MBのCVS形式にして検索できるようにしたものもあるでよ。

V3：XML版の機能

• オリジナルを動的に変換してXMLに。
  • 注釈は該当単語の開始位置、終了位置も入ってる。
  • データや変換スクリプトは追加可能。
    • V3の後の機能だけど、朗読のデータが手に入ったのでカラオケのように朗読位置を表示するためのデータを追加しているところ。
• XSLTでhtmlにして表示したり、WordのXMLにして印刷用データにしたりできる。
  • Fontも指定できるでよ。
    • 原文は行書、訳は楷書、注釈はゴシックとかすると雰囲気出るよ。
  • 縦書き機能が大人気だよ。源氏物語の好きな人はわざわざ手作業で縦書きにするほど縦書き好きだよ。
    • でもIEのせいで最初のページしか印刷できないよ。IE7でも同じだよ。しょんぼりだYO!
    • だからWordML版を作ったんだよ。

実演と説明

• IEにしか対応していないからIE限定の機能を使っているよ。
• tableの各カラムの幅も指定できるよ。
• 変換はクライアント側でやるからセキュリティの警告が出てしまいます。
  • HTMLアプリケーション（HTA）でやります。HDDに保存する必要があるときはHTAです。
• 俺：朗読が「すみこさん」ってあったけどにしおかすみこかなぁ。どきどき。
• 基本PHPとHTMLとJavaScriptです。
  • 書式設定とか、ユーザからアップロードされる部分もいろいろあるのでCookie使ったりいろいろ工夫してます。

HTAコード説明

• HTAなのにEUCだからいろいろ不思議です。
• XMLやXSLはJavaScriptでxmlLoadでロードします。
• データの埋め込みはscriptタグのtype="text/xml"でやってるよ。
• xmlLoadしたデータと埋め込まれたデータをひとつのXMLにして、XSLTで変換して保存している。
  • 保存のためにHTAでやっている。
  • wordファイルにするに当たって最低限必要なタグ以外はばっさり切ったよ。
    • HTMLと似た部分もあるでよ。

開発の振り返り

• XSLTの中でmsxsl:scriptっていう非標準タグを多用しているのでよくないよね。
  • シンタクスはXSLT、セマンティクスはJavaScriptにしてしまった。
    • もうちょっとXSLTでがんばるべきだったかも。
  • 一番苦労したのはルビを振ったり注釈部分を赤くしたりのところ。
    • タグの挿入がXSLTでどうしてもうまくできず、JavaScriptになってしまっている。
    • 何種類かの注釈が重なるとうまく階層構造にならないとか。
  • やっぱり標準でXSLTにJavaScript書けるようにしてほしいな。
• XSLTのデバッグができる素敵なツールないかな。
  • msxml:scriptタグ内のJavaScriptとかもう最悪。
    • やっぱり標準じゃないからじゃろか。
• PHPとかASPとかJSPは文字列埋め込みとか楽チンでいいねぇ。
• namespaceわかんね。
• XSLTのエラー処理ひどすぎ。
•  書きたいよう
  • 宣言すりゃできるよ。
    • マジで? 後で教えてください!

質問

• 村田さん
  • 源氏物語のテキストっていっぱいあるけど、どうしたの?
• 回答
  • 与謝野晶子訳はHTML版のときに対応させていた。
    • オリジナルのテキストとよく似た形で作っておいた。
  • オリジナルはネスケ4.0用で最適な表示ができるようになっている。
    • 行折り返し機能がないので、左に本文、右に訳を置くとうまく表示されるようになってた。

• ジャストシステム 小林さん
  • 聖書だと「第何章、第何節」ってのはどんな翻訳でも一緒。
  • 源氏物語ではそういうものはあるの?
• 回答
  • 人によってまるで違う。
  • 今回の「章、段」も渋谷教授がこれ用に分けたもの。
  • 渋谷教授の別のテキストでは段だけだったりする。
  • 学者さんはプライドもあるので、それぞれ違う主張をする。
  • ただし、無償で提供されているのは渋谷教授のこれだけ。
    • 趣味でやっている人たちは必然的にこれに従うことが多くなっている。
• さらにコメント
  • 渋谷源氏でネームスペース切ればいいんじゃないかな。

• アンテナハウス小林さん
  • フォントの選択メニューがあったが、あれは固定?
  • クライアントに入っている好きなフォントは使える?
• 回答
  • フォント選択の部分はメニュー形式ではなく文字列を入力するようになっている。
  • 入力する文字列はサンプルを下に出しているだけで、そのフォントがインストールされていればそのフォントで表示される。なければデフォルトになる。
• 小林さん
  • ワード文書の生成はサーバですよね?
• 回答
  • クライアントです。
  • V2のときに使ってたサーバが「高負荷のスクリプトはだめ」と書いてあったので、サイトを消されないためにサーバではやらなかった。
  • 今ならサーバでできるかもしれないけど、V3でもクライアントでやっちゃってる。

• W3Cの佐々木（！?）さん（たぶん聞き間違い。欧米系の方。）
  • 源氏物語もそのほかもXML化するプロジェクト（text encoding initiative） があり、タグセットが定義されている。それを使わなかった理由は?
• 回答
  • 不勉強で知らなかっただけ。教えてください。

• 熊本大学 大島さん
  • 朗読のデータとテキストの対応をとるとき、音声データの時刻情報を取るの?
• 回答
  • はい。
• 大島さん
  • フリーの音声認識ソフトを使って自動化できないでしょうか。
  • julius（?）ってソフトでそんなことをしている本があった。
  • 仕事で講演内容をe-larningのために加工しているが、それを自動化しているところもある。
• はじめの質問の小林さん
  • 自動化しても結局確認のためになめなきゃいけないですよね。
  • 音声を聞きながらクリックしてタイムスタンプを押すみたいなツールはありますよね。
• 回答
  • そういうのを自分で作ってやってます。
• 大島さん
  • 元テキストもあるからなんかできそうですね。
• juliusの関係者の人（京都高度技術研究所の山田篤先生（？））
  • 音声認識で言うアラインメントとかいう言葉だが、音素列を取って比較するみたいなことをすれば、可能。ただし現代日本語風の発音をしてくれていないといけない。
  • ブレス、無音区間の情報があれば、精度があがる。
  • 実はjuliusじゃなくてjulianというソフトを使う。
    • sourceforgeにあるよ。

• 村田さん
  • どれくらいかかっていて、そのうちの何割くらいが地道な作業で、何割くらいがプログラミングでしょう。
  • 与謝野晶子訳の修正とかは、5帖しかやっていない。ボランティアの方がついてくれて、時給千円で15万円くらいかな。
  • 朗読データは3回くらい聞けばできそうだから、80時間×3で240時間くらいかな。
    • これは聞くのも好きなので、自分でやろうかと思ってる。

Parallel Narratology（平行物語論） JustSystem 小林さん

自慢

• Ubuntu上のxfy上のSayYes!というプレゼンツールでやっている。

はじめに

• Parallel Narratologyは造語です。
• 同じことについてほかの人が違うことを言う。裁判の証言とか。
  • その典型的な例が聖書の福音書だと思う。
    • マタイ、マルコ、ルカは似てる記述が多い。
  • 現代ではマルコが一番古くて、マタイとルカがいろんな話を混ぜて読者に合わせて編集したといわれている。
• マタイ、マルコ、ルカを比較している「たいかん表」がある。
  • 写本にもあるし、ギリシャ語版も日本語版もたくさんある。
• まだHTMLが出てきてないころに聖書の電子化をしてハイパーテキストにした。
• 最近またHTMLにしてみた。
  • でも見づらい。
• で、作った。
  • 横に並べて見られるようにした。

一般的に展開できないか

• 芥川龍之介の藪の中
  • 読んだ人いる?
  • ちょっとしかいない。
• あるカップルが盗賊に襲われて、男が殺される。
  • そのシチュエーションの説明で、盗賊の首領と男と女の証言が違う。

並べてみた。

• 意外と対応するところが少ない。
  • 男が死ぬ瞬間は対応してる。
  • 視線の交換に着目してみた。
    • マークをつけて並べて見られる。
    • 男の死因についてみんな違うことを言う。
• どうして異なった発言に至ったか
  • 視線の交換を見ると…
    • 事実は藪の中でわからないけど、視線の交換から受け取った意図の誤解から、自分のプライドとかを守るために違うことをいっているんじゃなかろうか。

聖書の語彙分析

• それまでの聖書研究と違う結論が出てきている。
  • なぜか。
  • 語彙空間が主義主張を表すことはあまりないようだ。
  • マタイ、マルコ、ヨハネそれぞれの中では語彙空間があるかもしれないが、みんなが語彙空間を共有していたわけではないのかな。

山口さんから技術的な話

• STORYWRITER
  • ポイント
    • xhtml
    • 正しくマークアップされていればできる
  • マーカーをつけるとemタグとclassがつく。
    • おなじclassのものを並べて表示する。
    • markをsentenceにするとemタグの部分だけじゃなくてpタグまで並べる。
  • 段落になっていないニュースリリースとか（brタグで改行しているとか）だとうまくいかない。
    • 正しいマークアップ→見かけ上段落に見えるだけではなく、意味のあるまとまりで段落タグを使うとか。
  • 正しいマークアップがされていると、いろんなブラウザで正しく表示されるだけでなく、読み手に意図したことを正しく伝えやすくなるのですよ。
• 由来
  • テキストを置き換えた結果、話がつながるように書き換えて見たくなりませんか?

質問

• アドビシステム 山本さん
  • READERではなくWRITERってことでおもしろい。
  • それぞれのテキストの共通点を見出していろいろ記述していけるということだが、言葉（表現）は同じであってもその背景とか文脈は違う可能性がある。READERではなくWRITERというからには、読み手が自分なりの解釈を埋め込んでいけるってのがいいな。
  • 今後の発展の可能性は?
• 回答：小林さん
  • さっきいい足りなかったことを言ってくれた。
  • 将来的には「読む」と「書く」がシームレスになって、じゆうに
• くにしまさん（白いセーターに赤シャツの人）
  • マークをするときにオーバーラップしたくなると思うが、どうするのか
• 回答：山口さん
  • できません
• さらに
  • そこを何とか
• 回答：小林さん
  • 村田さんと佐々木さん（W3C?）にがんばってほしい
• 村田さん
  • 無理です。

構造化文書と符号化文字 ジャストシステム 小林さん 改め Lawrence Kobayashi-san

はじめに

• Unicodeは標準的になってきてるけど、日本語まわりでちょっと話題があるので。

ルビタグでの失敗

• W3Cへのルビタグの提案
• ユニコードにも提案した。
  • ルビタグの問題
    • 対応していない処理系がタグだけを読み飛ばすと問題になる。
    • 「羽虫（はむし）」が「羽虫はむし」になってしまう。（対応していないなら「羽虫」にしてほしい
• Unicodeのガイドライン
  • http://www.unicode.org/reports/tr20/

外字問題

• 符号化文字集合に含まれていない文字
  • 新しく作る
  • 図形で扱う（JISX 4166）
• 符号化文字集合で区別できない2つの字形（吉の上が士と土とか）
  • 例外処理で符合を増やす
  • 枝版として区別する
  • 図形情報を追加する

CharacterとGlyphの違い

• 龍と竜と中国の簡体字のとか。
  • 符号が違う
• 一角目が横になっていたり、右下の三本の横棒がテになっていたり
  • 符号は同じだけど、使い分けたいという要望がある
  • そういう無理難題がめぐりめぐってアドビの山本さんのところに行く。

VistaのJIS2004問題

• JIS X 0208:1978とJIS X 0208:1983で混乱した。
  • 森鴎外の鴎のバツカモメとシナカモメが変わった。
  • 表外漢字字体表が出てきた。
    • 表外漢字字体表の完成を待たずにJIS X 0213:2000を発効した。
    • JIS X 0213:2004が出てきた。
  • ジャストシステムは一太郎ですぐに対応
  • MSはOSの切り替え（Vista）を待たざるを得なかった。

日本語サブレパートリー

• 自国と関係ない部分を無視して関係あるところだけUnicodeから切り出すのがサブレパートリーという機能
• 日本語サブレパートリーは勝手に足したり引いたりしている。
• CP932（JIS X 0208＋α:丸付き数字とか）をCOMMON JAPANESEとして入れた。
  • 村田さん：コレクション? CLDRではない?
  • コレクションです。
• 10646で見られるので0208も
  • 村田さん：委員長としての意見?
    • 個人です。
  • ねずみ色のタートルネックの人：Unicode Standardには入ってないですよね。
    • Unicord Standardは参照できるけど10646は参照できないとかあると困る。
  • 10646にしかない。
  • 内輪になって皆さんぽかんとしてるけど。

Valiation Selector

• Glyphの区別の仕組み
• すんなり企画に入った。
  • しかしなかなか漢字に適用されなかった。
    • モンゴル文字とか数学記号のいくつかの形の違いの対応に使われてた。
    • 日本から反対の主張があったため。
  • 区別すべきではないのに区別されると困る人もいるから。
    • 税金の納付通知書で字形が違うから「俺じゃない」と言い張るとか。
• Adobeが字形のためにプライベート領域を使いたいという提案があったためけど、プライベート領域をパブリックユースで使われると困るのでこれを使わせることにした。
  • ただし登録制とした。
  • 登録一号がAdobeのAJ1-6

アドビシステムズにおけるIVSへの取り組み アドビシステムズ 山本太郎さん

はじめに

• 20年位前に事務機械工業会か何かでSGMLのなにかの翻訳とかをやってわけがわからなくなった。
• JISの例示字形の変更にも苦労させられた。

IVS(Ideographic Valiation Sequence)

• 基本の文字のコードに字形選択子をつける。
  • 240個区別できるよ。
• 世界共通の字形選択子にはなっていない。
  • 登録制になっていて、領域ごとに提案する。
  • Adobe-Japan1文字コレクション
    • http://www.adobe.com/devnet/font/pdfs/5078.Adobe-Japan1-6.pdf

登録

• http://www.unicode.org/ivd
  • 基底文字の追加が必要ないくつかを除いて登録された。

文字セット

• Adobe−Japan1-0〜6まで、どんどんいろんな業界で使われる異体字や記号など追加して拡張されていった。
  • 5、6ではJIS X 0213:2000、U-PRESS対応みたいな最近の文字コード関連の対応。
  • ねずみ色タートルネックの人：U-PRESSの対応はどうなってるの?
    • 全部じゃなくて一部除いて対応している。NTTのフリーダイヤルのマークとか。

環境整備

• 入力できるようにする環境としてフォントとかIMEとか各アプリケーションの対応をがんばってる。

ジャストの人からデモ

• 芦田さんは芦屋のお嬢さん。

村田さんから一言

• 45分押してるんだYO!

XML時代のInput Method ジャストシステム 舛形（ますがた）さん

XML時代?

• 勝手にタイトル決められたんだYO!
• 情報はXMLで表現する時代。
• 情報はXMLであると期待する時代。
• 情報はXMLでなければならない時代。

なぜ?

• 処理しやすい
• 木構造で表現力に富む
• 標準のボキャブラリがたくさんある。 xhtml、mathml、SVG、SDRL…

それだけじゃないよね

• 多面性の担体
  • microformatsでWebページがカレンダーになったり
  • ドキュメントだけどデータだったり。
• 人が読むドキュメントに機械可読なデータを重畳
  • リンクとか。

人が書く

• human readable → editable
• xfyでXMLのグラフィカルな編集
  • 開発者じゃなくて一般人がワープロ感覚で

InputMethodで書く

• いくらワープロ感覚でもまだめんどい。
• 変換したときに「6時から」とあったらdtstartだろと。12/10のエントリだとか12/21って直前にあったとか午前とか午後とかは変換候補のひとつだと。
  • お店を入れたらそのwebサイトとか地図とか。

XML-IMで入力すると

• 楽チンになる
• 知らない人にもXMLを入力させられる。
• 間違いの指摘とかもIMだったらできるよね。

実装の話

• JavaのIMの書き方にのっとって作ると非対応のものには普通のIMに見える。
• クライアントと相談しながらやる。

固定観念

• IMは仮名漢字変換のためのもの
• IMは東アジアのもの
• IMはアプリとは独立のもの
  • Eclipseの補完だってIMみたいなもの。
  • 使えれば東アジア以外だってみんなうれしい。

まとめ

• XMLマンセー
• xfyとXML-IMならみんながXMLを書く世界を実現できる。
• 自分だけじゃなくてみんなのために。
• 日本は世界最高のIM技術を持ってるのでがんばろう。

村田さんから一言

• 続けていこう。まいてくよー

XML-IMでタグ付けされた文章を使う例 東京大学 熊谷さん

背景

• 自分に関する情報がたくさんあるけど管理や活用ができてない。
• いろんなことをしてくれる秘書さんを作りたいよ。
• 自分の情報は自分で集めて管理しよう!

課題

• 入力負担を減らしたい
• 文章データをビジュアル化したい！

デモ

• ブラウザ上のタグ（microformatsなど）のついた文章をコピーして、クリップボードにappendしていく（コピーじゃなくて追加コピーなのがポイント）。
• 一覧するとそれぞれの場所のgoogle mapが出るよ。
  • それだけじゃつまらないから経路も出せるよ。
  • 経路検索エンジンは自作です
• そのままblogにアップしちゃうよ!
  • KMLで吐き出してgoogle map上で使うこともできるよ！

メリット

• 使う側も管理者側もいろいろあるよ。まいてるよ。

展開

• 共有化したり
• メールから自動的にスケジュールにしたり

課題

• タグの標準化
  • microformats?
• タグの拡張
  • スケジュール以外にも
• 辞書
  • 場所情報をユーザ情報に入れるとか。

まとめ

• XML-IMが普及すればうれしいと思うよ!

質問

• 村田さん
  • まいてくれてありがとう!
  • 同じものでも入れたいタグが違う場合どうする?
    • hCalendarとgoogle Calendarのタグとか。
• 回答：舛形さん
  • その辺の吸収するために候補を人に選択させるようにしています。
• 村田さん
  • アプリのほうから入れられるタグを提案できるような仕組みが合ってもいいかもね。

OOXMLの投票結果とballot resolution meetingの予測 国際大学 村田さん

はじめに

• 泥臭いです。
• 若い人は真似しないでください。10年来の知人を信用できなくなります。

OOXMLへの批判

• OOXMLはMSべったり
  • MS Officeはたくさん使われてる
• ODFがあるのに。
  • 矛盾しないし変換できるし。
  • PDFがあるのにxhtmlがあるじゃないか。

投票結果

• 2/3に満たなかった。
  • 失敗ではなく、現時点で足りないだけ。
  • コメントをつけて反対しているところが、コメントが受け入れられたら賛成に回ることもよくある。

Ballot Resolution Meeting

• ODF、知的所有権の話はされない。
• 文面の修正つながることだけ。
  • それ以外は議長に止められる。
• ODFとの関係が気になるところはどうすればいいか
  • Noに投票し続ければいい。

もめる?

• もめる要因の話（ODFの話とか）は一切されないし、されそうになれば議長が止める。

議長

• イギリスの個人会社の社長。若い人。
• 最悪の仕事らしい。

準備中

• 各国のコメントに制定母体が回答を準備中。
• 回答が難しい話はBRMで議論する。
• 簡単なところは回答がもう来てる。
• ECMAは各国のコメントを公開してはいけないというルールがあるので非公開。
  • 各国が独自に公開するのはOK

制定している人たち

• MSの人が多いけど、そうじゃない人も多い。
• コメントには真摯に対応している。

SC34

• 最終的にはODFもOOXMLもSC34にくる。
  • 日本は幹事なので割と権限がある。

ODFの欠陥

• JISにするため翻訳したりしているところでいろいろ見つけた。
• 報告もしてる。
• 100の単位で意味不明なところとかある。
• そのうち正誤表が出るのかな?

OOXMLの欠陥

• 大きいので1000以上あるはず。
• 直せるんじゃろうか。

拡張

• どうなるの?

ODFとOOXMLの両方を考慮する活用

• DIN（ドイツ）でやってる
• 相互変換とか、変換して戻したときの欠落をさせないとか。

個人的意見

• オフィス文書交換の規格なんてうまくいかないと思ったけど、2つも出てきて一応はどちらも動いてる。
• 出ないよりはいいよね。
• もともとXMLだってSGMLと矛盾してるし。
• RELAX NGだってXML Schemaと矛盾してるし。

質問

• アンテナハウス 小林さん
  • BRMの結果の判定はどうするの?
• 回答
  • 一つ一つのコメントに対して、修正内容が出て、のめるとかのめないとかになる。
  • 全体としての合意は一切されない。最終的には各国が自分で賛成するか反対するか。
• ジャスト 小林さん
  • 会議中に発言したのは?
• 回答
  • 村田さんはオブザーバとしていろいろ言った。うるさかったのは村田さんだけ。
• リコー yoheiさん
  • AppleはどうしてODFじゃなくてOOXMLなのか
• 回答
  • わからん。Appleの実装はデモを見る限りすばらしい。
  • MSがAppleにOffice製品とられるんじゃないかと心配するくらい。

AtomPubの概要説明とInteropの結果報告 NTTコミュニケーションズ 朝倉さん

はじめに

• タイトルは事務局に指定されたんだYO!
  • だから勝手に変えました。
• 会社名の「ズ」を落とさないでね。

自己紹介

• NTTグループ内のR&Dセクションで標準化活動くらいまでやってるよ。

積み重ね

• TCPの上にHTTP、その上にXMLでさらにその上にAtom、AtomPubが載ってるよ。
• インパクトのあるのはAtomPubのほうじゃろうか。
  • RFCも5000番台になりました。

AtomPubとは

• ざっくりと、フィード情報をサーバにアップロードするためのプロトコル。
• RFC4287のフォーマットとRFC5023のプロトコル
• 従来との違い
  • FTP、SCP、…：ファイルじゃなくてWebリソースの転送
  • WebDAV：HTTPの拡張じゃなくて応用。階層構造じゃなくてリンク関係。

インパクト

• CGMのAPIの共通化。
• 組み込みに。
• ネットワーク上のリソースマネジメントのやり方のひとつとして。

AtomPubのさわり

• CollectionとMember（リソース）と。workspaceはあんまり意味がないのかな。
• リソースのCRUDができるよ。
• CollectionはFeedだよ。MemberはEntryだよ。
• 具体的なコード例は朝倉さんの発表資料を見てくれ。
  • CollectionにEntryをPOSTすると追加されるよ。
• 画像みたいなEntry文書にならない文書はMedia Link EntryっていうリンクだけのあるEntryで扱うよ。

簡単だね!

• いろいろ考え始めるとはまるところもあるよ。
  • CollectionにCollectionをPOSTするみたいなはまりどころはAtomPubでは未定義。

相互運用性重要。

• どこか1社の独自仕様が広まっていく幸せな時代は終わった。
• 標準化なんて無駄だよ。
  • 重要なんです。

IETF

• 企業が実装を伴いながらde-factoを作っていく。
• XCap知ってる?
  • ぜんぜん畑違いのところでXMLが使われてる。
  • 村田さんも知らなかったらしい。
  • XMLの操作言語?
  • 複雑なんだけど通っちゃってどうなんのかね。

IETFでの攻防

• Slug ヘッダ
  • RFC822に引っ張られて日本語はかけなかった。RFC2074で書けるけど難しすぎる。
    • 主要言語にはライブラリもないし。
  • まずいので文句いったけど、誰も見向きもしてくれない。
    • 「何か問題でもあるの?」って言われた。
  • 別のエンコード方式にしようと提案したら流されそうになった。
    • UTF-8＋パーセントエンコーディングを提案した。
    • 炎上。反映。朝倉さんGJ。

GoogleでのInterop

• Joe Gregorioすげぇ。
  • C#のコードあげたらすぐJavaに直しちゃったよ。
• Joe ChengのWindows Live Writer作ってる。すごいよ。

日本でもやった。

• 少ないYO!
• もっとおいでYO!

まとめ

• 実装と標準が両方ないとだめだよね。
• 応用に進むのかな?
• 相互接続試験、声かけてくれればまたやりますよ。

最後に

• 会社の戦略に影響を与えながらがんばってる人多いよ。
• 新しいことをやるとき大変だけど、たまに拾ってくれる人もいるよ。がんばれ。
  • 足りない部分を拡張したり。

質問

• 村田さん
  • Feedの拡張はタグを増やせばいいのはわかるけど、プロトコルの拡張ってのはどうやるの?
• 回答
  • 未定義の部分を引っ張り出して、新たにRFCに起こしていくとか。
• NTT 井上さんによる補足
  • プロトコルの拡張という意味ではクエリのパラメータのつけ方とか、SNSで使うときのやり形とかが今進んでる拡張。

Atomの拡張の検証方法 村田さん

たとえば

• たーくさんあります。
• 例も見せてくれました。
  • gdataとかgCalとかOpenSearchとか。
  • AtomFeedに見えるけど、実はGoogleカレンダーのデータです
    • 小林さん：保育園に送る以外仕事してないじゃない。
    • これはサンプルなの!
  • sageでも読めます。

Google Calendar

• Atom + OpenSearch + Gdata + Google Calendar
  • Geo RSSやYahoo Mediaもはいるはず。

拡張のスキーマ

• スキーマが未完成なので検証できない。
• 仕様書が読みにくい。
• プログラムが書きにくくなる。
  • 入れ子のEntryとかを読んでしまうとか。

スキーマの書き方

• 一枚岩でがんばる
  • RELAX NGで書かれたAtomスキーマのモジュールを整備してほかと組み合わせられるようにする。
  • 拡張3つくらいが限界?
    • 村田さんがやれば5つくらいまでできるかもしれないけど、後で読みたくないものが出来上がるだろう。
• NVDLを使う。
  • それぞればらして検証する
    • どう組み合わさっていたかの情報が落ちるので若干ゆるくなるけど。
  • サブスキーマをそれぞれ書く。
    • 分割してから検証器にかける。
  • サンプルコードを見せてくれた。
    • 名前空間をみて、それに対応するスキーマを呼び出す。
    • Atomの中にgdataがでてきて、その中にさらにAtomが出てくるとかもある。

NVDLの動作デモ

• AtomのrngスキーマはいったんAtom以外が出てくるとその中は全部あきらめる。
• 分割してやると検証ができる。
• 英語よりスキーマのほうが読みやすいよね!

質問

• ジャストの小林さん
  • NVDLでばらすと何が落ちるのか
• 回答
  • 簡単に言うと何がどこにあったかという情報だが、最悪なのはidを参照していたりした場合に終えなくなる。
• さらに
  • そういうのを検証したければほかの方法でやれということか。
• 回答
  • そうです。全部をこれでやる必要はない。

NVDLによるXML複合文書の配送と再構築 宮下さん

XML複合文書

• いろんなところで使われてるよね。
• 利点
  • さまざまな語彙を組み合わせて文書を記述できる。
  • 既存の語彙を拡張できる。
• 現実は厳しい
  • 名前空間の現実的な使われ方が理想的になっていない。
    • 適当に名前の衝突を避けるためだけとか。
    • ひとつの名前空間がひとつの意味を持っているわけではないとか。
    • 循環参照しまくりとか。
  • アプリケーションがすべての名前空間を知ってなきゃいけない。
  • 名前空間を入れるとスキーマが難しくなる。

やりたいこと

• 複雑な複合文書をシンプルにして処理したい。
• 出力は?
  • ばらばらになっちゃったYO!
  • SnRNVというツールを使うとばらばらになった結果を出力できる。
    • EclipseのCVSにコミットされてるよ。
  • ばらばらになった結果には変なタグが入ってる。
    • Unicodeの変な文字を埋め込むという手もあるらしい。

処理例

• xhtmlを含んだAtomを分割したり編集したり。
• SnRMVはSAXでThreadが暴れまわって大変でした。
• 分割して変更するときに変更されていないものも保持していて、埋めておいた復元ポイント情報を消されても対応できるようにしている。素敵。
• 間違えて消しちゃってもそれなりにがんばってValidなXMLに再構築するよ。

Webアプリの例

• googleCalendarのFeedを読んで表にする。
• JRuby on Railsいいっすよ。
  • JavaのモジュールのSAXハンドラがrubyで継承して実装できる。
    • コアなライブラリをほかの言語で書いてデモ用のWebアプリの部分だけをrubyで楽にかけるのがいいかも。

今後

• XProcとかに期待してます。

質問

• リコー yoheiさん
  • グローバル属性はどうなるの?
• 回答
  • おとといの夜に対応しました。
  • Virtual Elementとして別にしまわれて何とかなる。
• ジャストシステム 山口さん
  • 島の数はあきらめたほうがいいと思ふ。
• ジャストシステム 小林さん
  • もともとのgoogle Calendarの吐き出すデータが汚いのに何とかなるわきゃない。
• 回答：村田さん
  • AtomとかRSSはRDBに入れるために平たくなってる。そして拡張もそれを踏襲している。なんでXML使うんですかね。これから拡張する人はもっときれいにXML使いましょう。
• ジャストシステム 舛形さん
  • NVDLはよくわからんけどスキーマでなんとかならないの?
  • プレースホルダはxincludeにならないの?
• 回答
  • スキーマ：スキーマだとつらいです。NVDLで簡単にしたほうが言い。
  • プレースホルダ：最初の村田さんのアイデアだった。ただ打たれ弱い（なくなると死ぬ）ので、もうちょっと柔軟性を持たせた。
• さらに
  • フォールバックの仕組みってあったんでは?
• 回答
  • 条件判断とかあったっけ?
• さらに
  • なければ「代わりにこれを入れる」が書ける
• アンテナハウス 小林さん
  • IDの衝突、相互参照が解決できないってのは何とかなります?
• 回答
  • 今はアイデアないけど何とかしたい。
• 濃いグレーのパーカーの人
  • 使う人はどうすんの?
• 回答
  • メソッド書いてがんばって呼んで。
• さらに
  • どっかで刺さると全体がとまる?
• 回答
  • Threadなので、タイムアウトとか入れれば止まらないよ。
  • プログラムでタイムアウトで進んじゃうとかってひどいから現実的には止まるだろうけど。

最後に：村田さん

• 今回は時期が時期なので20人なんて取れないだろうからオフィシャルの懇親会は無しです。ごめんなさい。
• 来年もまたなんかやります。

Permalink | コメント(5) | トラックバック(0)