Mozilla、XFormsを実装へ 78
ストーリー by GetSet
新たなる成長のために 部門より
新たなる成長のために 部門より
Silphire 曰く、 "Mozilla Foundationは、Mozillaに「XForms 1.0」の機能を追加する、というプレスリリースを出しました（参考リンク：XFormsのプロジェクトページ / 本家ストーリー）
XFormsはXHTML 2.0の一部としても使われる事が決まっており、どういう事ができるのかについては、developerWorksのSVG and XFormsを見るとよく分かるかと思います。SVGとXFormsでこれだけのインターフェースを作れるとなると、MozillaへのXFormsの実装が非常に楽しみですね。"
Native じゃないんで、日本語を貼り逃げ (スコア:5, 参考になる)
-
dW : XML : SVGとXForms: Rendering Custom Content （カスタム・コンテンツの描画） [ibm.com]
おまけ新しいSVG 1.2でXMLベースの拡張機構を使う
2つの技術と、それらをいかに融合するかを知る
次世代のWebフォームを利用して、あらゆるプラットフォームに適した拡張可能なオンライン・フォームを作成する
Re:Native じゃないんで、日本語を貼り逃げ (スコア:0)
Re:Native じゃないんで、日本語を貼り逃げ (スコア:0)
どーでもいいが、英語版のドキュメントを書いてる半分以上はNativeじゃないぞ。
こんな規格要らないと思う (スコア:2, すばらしい洞察)
「単純で、
どこでも似たようなかたちで表現される・使用できる」
ってのが第一の理由だと思う。
サイトごとにUIの不統一を引き起こし、なおかつデータ
構造を複雑化する規格の導入がなぜ必要なのだろう。
そこまでのことをしたいならFlashのほうが先行してい
て、しかも成功している。
ほとんどエンジニアの自己満足だと思う。
Re:こんな規格要らないと思う (スコア:5, 参考になる)
Flashとは考えているレイヤーが違うのです。
参考までに、以下にXForms1.0の仕様書にあった概要を引用しておきます。
“XForms is an XML application that represents the next generation of forms for the Web. By splitting traditional XHTML forms into three parts—XForms model, instance data, and user interface—it separates presentation from content, allows reuse, gives strong typing—reducing the number of round-trips to the server, as well as offering device independence and a reduced need for scripting.”
http://www.w3.org/TR/xforms/
＃実際にHTML Formをいじっていれば、現行のFormじゃ力不足とは感じるはず
Re:こんな規格要らないと思う (スコア:2, 参考になる)
そういう意味では，XForms仕様に限界を感じたときに，どうするかについて，XForms仕様自体が，何らかの指針を示してくれていたら，ありがたいなぁと思いました．
http://www.surguy.net/articles/clientside-xsl-taglib.xml
とか．
Re:こんな規格要らないと思う (スコア:1)
ただし、多くの場合、情報構造体なんて物を考えてFlashコンテンツ作る人が少ないのと、見た目と情報の乖離が激しい場合が多いので、誤解されやすいのかもしれません。
＃だからと言ってActiveXに行く気はしないわけで、xFormsは歓迎です。
Re:こんな規格要らないと思う (スコア:1)
あれのためだけにサーバーに変な小細工しなけりゃならんエンジニアの身になってくれ。
Re:こんな規格要らないと思う (スコア:0)
webは制限のあるGUIだから (スコア:0)
Re:webは制限のあるGUIだから (スコア:2, すばらしい洞察)
現在のWebの限界点が低いとしても、進化する試みまで否定することはないのでは。
その昔、Webに動きを与えんと実装されたJavaScriptなる言語は淘汰されたでしょうか。将来的には淘汰されるかもしれません。しかし、JavaScriptの代替になりうる技術開発及び実装がなければ淘汰されることはないでしょう。どんな技術も実装という土壌が整わなければ使い物になりません。現在のWebで満足しないのなら、新しい試みは受け入れるべきかと。結果的に淘汰されるなら、それはそれでよいことかと。
使用する環境のことを考慮するのはページ記述者に必要な注意であって、ブラウザ側が新しい技術を実装していくことは良いことではないでしょうか。ブラウザは先進的に、ページ記述者は保守的に、というのが望ましい姿だと私は思います。
ページ記述者は、ブラウザが新しい技術を実装しても、互換性を重視するために旧来の技術を使うことを選べます。現に、私などは互換性を重視してXHTMLではなくHTML4.01を好んで用いています。
--労使曰く、ひとごとを尽くして神頼み--
Re:webは制限のあるGUIだから (スコア:1)
＃もうちょっとWindows上でも安定して動いてくれるといいんだけどなぁ、
Re:webは制限のあるGUIだから (スコア:1)
Re:webは制限のあるGUIだから (スコア:1)
なぜいまだにアレを直してくれないかなぁ。
Re:webは制限のあるGUIだから (スコア:1)
Re:webは制限のあるGUIだから (スコア:1)
揚げ足取りとかでなく、単純に気になるので、教えてくれると嬉しいです。
Re:webは制限のあるGUIだから (スコア:2, 興味深い)
プロのパンチャーさんは、画面の機能や入力順や反応速度が入力時間に顕著に現れます。
雇い主は、１件コンマ３秒の短縮が月間パート経費がいくら削減されるか、
という事を考えて、入力画面の変更依頼があがってくる事もあります。
（まさにコンマ単位でタイムを削るチューニングをしている感じ）
とてもブラウザごときに置き換えられるモノではありません。
#１件コンマ３秒とかはちょっと言い過ぎ
Re:webは制限のあるGUIだから (スコア:2, 興味深い)
ブラウザでも使える、専用UIでも使える。それがいいんじゃん。
Re:webは制限のあるGUIだから (スコア:1, すばらしい洞察)
とかいう話はかつてよく聞いた気がするけど、いつのまにか10Gすか？
Mozilla vs MSIE (スコア:1)
ちょっと心配です。
And now for something completely different...
Re:Mozilla vs MSIE (スコア:1)
Re:Mozilla vs MSIE (スコア:0)
Re:Mozilla vs MSIE (スコア:3, すばらしい洞察)
見た目をつかさどるのはCSSです。
MSIEには (スコア:0)
Re:MSIEには (スコア:0)
Re:MSIEには (スコア:1, 参考になる)
XFormsはサーバへ送るフォームデータのための仕様なので、XULとは用途が違うと思うけど。
Re:MSIEには (スコア:3, 参考になる)
というか、そもそも、この仕様への対応は、そういうエンタープライズ市場への対応を念頭に置いているのだと思います。Mozillaに実装されているにもかかわらず、いまだに活かされていないSOAPなどの実装を活性化させるには、こうした複雑なデータ処理に対応して、力を発揮できることをアピールする必要があるのではないかと。
そうでなければ、Mozillaを、webブラウザじゃなくて、webサービス用のモジュールとして利用して欲しい、という狙いもあるかもしれないし。
Re:MSIEには (スコア:3, 興味深い)
同感です。
現状のWebアプリの弱点は、貧弱なUIと印刷機能ですよね。
今リッチクライアントの選定を行っているところは、
多いと思いますけど、ブラウザ標準で、ある程度のことが
できれば、選択肢は変わってきますね。
その意味で、webサービス用のモジュールというのは、
良い方法かもしれないですね。
Mozillaでブラウザ抜きの配布ライブラリ的なものを
用意してくれれて、Eclipseのプラグインでも出来れば
利用は見込めるかも。
あとは、PDFに頼らずに印刷したいので、
XML-FOを直接レンダリングできる機能を備えてくれると
文句無いんだけどなあ。
XFormsとPaged Media (スコア:2)
> XML-FOを直接レンダリングできる機能を備えてくれると
> 文句無いんだけどなあ。
MozillaはGekkoエンジンなので，XSL-FOよりは，CSS Paged Mediaプロパティ群 [w3.org]のほうが，先に実装されていきそうな感じがしますね．XSL-FOの将来性ってどうなんでしょうか．
ちなみに，ぼくは今，マークシート印刷原稿の定義ファイル(としても使えるような調査票媒体非依存な設問構造定義ファイル)を，XHTML2+XFormsで記述できるようにしようとしています(開発協力者募集中です! [keio.ac.jp])．ここでは，内部的に，XSL-FOを使っているわけなのですが，ApacheプロジェクトによるXSL-FO実装のFOP [apache.org]には，苦労させられています…．
MozillaZine の記事 (スコア:1)
今更かも知れませんが、このトピックについて MozillaZine と MozillaZine 日本語版で記事 / 邦訳記事が提供されています。
それから、Web Forms 2.0 [whatwg.org] などについて WHATWG [whatwg.org] のメーリングリスト [whatwg.org]で活発な議論が行われています。
セキュホの予感 (スコア:0)
と、適当なことを言ってみる。
かつてのNetscape 4.xと (スコア:0, 余計なもの)
Re:かつてのNetscape 4.xと (スコア:0)
無駄骨 (スコア:0)
実装したって使えないんじゃ誰も相手にしませんよ
Re:無駄骨 (スコア:0)
Re:W3Cに核爆弾を落すべきだと思う (スコア:1)
Re:W3Cに核爆弾を落すべきだと思う (スコア:1, 興味深い)
標準化標準化といいながら、規格ばっかり大量生産しやがって。
HTML一族だけで何種類あると思ってんだっつーの。
どれも本来の意味での標準にならないうちに、次の規格の
策定に移ってばっか。
自分で仕事を増やしたあげくに、それを標準とよんでりゃ
世話ねえよ。けど、つきあわされる身にもなってみろってね。
それら思いつきで次々策定されていく規格は、セカンドシステム
効果満載。前のバージョンに、思いつきで次々とくっつけていくから
複雑怪奇かつ醜悪きわまりない。しかも前のバージョンと互換性が
ないことも多々。
いやいいんだよ。コンピュータ便利屋の漏れとしては、
規格や標準とやらが複雑になればなるほど一般人の手には
負えなくなるわけで、それだけ飯の種が増えるわけだからさ。
だけど、一人のWWWユーザとしてはだ、もっとシンプルな方が
いいね。誰でも手軽に情報発信（←死語？）できるのがWWWの
いいとこじゃん。内容以前のところで格差をもうけて
どうすんだって。
Re:W3Cに核爆弾を落すべきだと思う (スコア:1)
Re:W3Cに核爆弾を落すべきだと思う (スコア:2, 興味深い)
しかし、この1990年に書かれた記事 [archive.org]が、面白いくらいに今の状況を説明しているところをみると、この風潮は今に始まったものではないのでしょう。
Re:W3Cに核爆弾を落すべきだと思う (スコア:1)
XFormsのようなものは、‘HPビルダー’のようなソフトによって、
ラッピングされたうえで、WWWユーザに届けられるのです。
見る側に立ったときは言うまでも無く。
＃まぁ、XHTML1.1の必要性とかは正直疑問ですが・・・
＃とはいえ、XFormsは必要な規格だと思う。
XForms / Wrapping (スコア:1)
同じような視点を持っています。低位のレイヤーがより高度に実装されることで、それより上位のレイヤーが作られ得る、また作られるだろう、ということですよね。例えとして微妙ではありますが、Java に対する、Struts 等のフレームワークのように。
Re:W3Cに核爆弾を落すべきだと思う (スコア:1)
仕様に文句があるなら，W3Cの公開メーリングリストで問題提起してみてはいかがでしょうか。
あと，親コメントには「思いつき」って2回も書いてあるけど，そんなに思いつきで仕様決めてるとは思えないんだけどなぁ。
Re:W3Cに核爆弾を落すべきだと思う (スコア:1)
HTML 2.0の時点で既にそういう仕様だったので，それを引きずってHTML 3.2，HTML 4.0/4.01 ≒ XHTML 1.0/1.1 と来たんでしょう。そういう仕様を作った元凶は少なくともW3Cじゃないです (HTML 2.0はIETFによって策定された) 。で，現在策定中のXHTML2ではその問題を解決する方向で動いています。
Re:W3Cに核爆弾を落すべきだと思う (スコア:1, 興味深い)
HTML 4.01以前のHTMLはタグの省略機構上の制約から、P要素は終了タグが発生する前に他のブロック要素が現れたら終了タグは省略されたものとみなします。
PにBLOCKQUOTEが含めないというのは、思い付きではなくHTMLという仕様上で記述者に配慮するための必要悪ではなかったでしょうか。
インラインレベルにはBLOCKQUOTEの代りにQがありますし。
リストについては欠陥に近いですが、そもそもタグの省略という概念がブロック/インライン共用の要素の存在が難しい理由かと。ま、省略機構に助けられている人間も多いようですが。
Re:W3Cに核爆弾を落すべきだと思う (スコア:0)
Re:W3Cに核爆弾を落すべきだと思う (スコア:0)
まずW3Cの実体であるMITとINRIAと慶應大学に核爆弾を落とさなきゃ。
関東に住んでる人は大丈夫なのかしらね。
Re:もうMozillaはいいですわ (スコア:1)
作る側としてはまだまだMozillaの方がまし。
でもIE7ですごいことやってくれればIEはNN4.x当時のIE4に成れるかも。
Re:もうMozillaはいいですわ (スコア:1)
なんか Mozilla のバージョンがあがるたびにさくさく動くように
なって感動してるんすけど、この６年。つーかバージョンがあがる
ようになったこの２、３年くらいか、もうすこしだけ正しくは。
Cyrix M2 280MHz でも最近の Mozilla なら Lynx のバックアップ
には使えますです。FireFox じゃまだきついけど。
Jubilee
Re:もうMozillaはいいですわ（オフトピ） (スコア:2, 参考になる)
>あんまりMozillaってわくわくしないんですよね。ただのユーザー側からすると。唯一わくわくするのはActiveXを真似た新プラグイン仕様 [mozilla.gr.jp]ぐらいで。
少なくとも、XFormsへの対応は、あまりエンドユーザー向けのものではないです。それより、エンドユーザー向けには、FirefoxやThunderbirdのRSSへの対応の方が面白いかもしれませんね。
Firefoxのブックマークツールバーから直接RSSフォーマットのデータが読み出せるようになります。
>実際FlashなんかはMozillaやOperaで再生するよりIEのActiveX版のほうがはるかにスムーズにアニメーションしてくれますから。
うーん、それは、mozillaが悪いのか、macromediaが悪いのか、なんともいえないです。まあ、IEがネイティブに最適化している、というのはあるかもしれませんが。
> Opera、Mozillaの場合はハードが良くなってもたいして早くなってませんね。なんか違いがあるんでしょうかね？
Mozillaはともかく、Operaが早くならない、というのは、ちょっとおかしいかも。ハードウェアをみているわけではないので、なんともいえないですが。あと、mozilla自身は、1.7以降、かなり早くなっています。まあ、メモリ食いな性格は変わりませんが。
Re:もうMozillaはいいですわ（オフトピ） (スコア:1)
> 一部のオタユーザーだけだと思うのだが。
ここでいう「エンドユーザー」ってのは、「開発に関わらないブラウザの一利用者」って意味です。「初心者」とか「非テクノロジー系の一般ユーザー」って意味ではありません。