atomに関するbutyricacidのブックマーク (3)
-
で、今ざくざく見ていたのだけれど、やっぱり全文配信のほうが読む人には親切だよなぁ。書く方としては反応がほしいために要約にしているのかなぁと思うのだけれど、よっぽどおもしろいものを書いている人以外は、題名だけでスルーしてしまう。これが全文配信ならとりあえず、目を通す。 http://d.hatena.ne.jp/t___s/20080126/1201312295 読み手と書き手の事情の違い 読む側のことだけを考えて書きます。 全文は技術的な方法で要約にもなるんです。フィードリーダに初めの100文字だけ表示するといった機能、重要な箇所を抜き取る機能*1があれば要約になるんです。つまり全文は要約を含むということに。全文や要約は読み手にとってどちらがいいかなんて人によるものなので、カスタマイズできる﹃ツールの機能﹄として提供されているほうが親切です。 書き手のことを考慮すると事情は変わります。ペー
-
AtomPub がついに RFC になりました! RFC 5023 The Atom Publishing Protocol RFC 5023 The Atom Publishing Protocol(HTML) 関係者のブログ Joe Gregorio: RFC 5023 - The Atom Publishing Protocol Sam Ruby: <appdraft>no<app:draft> RFC になるまでずいぶんと長かったように感じますが、 その分完成度は上ったのだと思います。 interop もすでに何回も開催されており、その結果も良好です。 AtomPub は全ての、とはいかないまでも、多くの Web サービスのベースとなることが できるプロトコルです。 たとえば blog、何らかのデータベース、画像/映像リポジトリ、 Wiki、カレンダー、ソーシャルブックマークなど
-
Tim Bray からアナウンスがあったとおり、 APP の標準化作業がほぼ終了しました。 RFC 番号が付くのはしばらく先だと思いますが、 現状の仕様を実装してもう問題ありません。 最後の draft-17 ベースの仕様が RFC になります。今後の修正はeditorial なものだけのはずです。 この先、Web API を設計する人は、まず APP が利用できないか検討しましょう。 APP を採用すれば自然と REST スタイルを採用することになります。 これまで悩みがちだった Web API の設計が、かなり楽になると思います。 Web API を設計する人は、オレオレXMLを設計する前に、Atom/APP をベースにしたらどうなるか、 を考えて見ましょう。きっと Atom/APP は良い選択肢になってくれるはずです。 日本では AtomPP で定着しつつあった Atom Publ
-
1
全文配信とニコニコ動画の共通点 - Tosikの雑記
yohei-y:weblog: AtomPub が RFC 5023 に/日本語訳を公開します
yohei-y:weblog: APP の標準化作業がほぼ終了
