アカウント名:
パスワード:
ていうかですね、入力するシステムまで官庁が用意するのが おかしいんですよ。
国の事務関係のファイルフォーマットとその送付方法だけ 定めれば、あとは(Intuitとかみたいな)民間が使い勝手の よいアプリケーションを開発・販売するのではないか?
そこを官庁が使い勝手と品質に劣るシステムをわざわざ作って 無料化とかやるから民間のビジネスチャンスは潰すわ、 駄目システムで利用者を減らすわ、縦割り弊害でコストは かかるは電子政府をせっせと潰しているんだから世話ないと しかいいようがありません。
元ACですが、クライアント側で各アプリケーションが 独自に色々なことをするのははっきりいって望ましい。
例えば会計ソフトに申請機能を組み込む、CADソフトに 建築設計の審査申請機能を埋め込む、などなどです。 もちろん拡張部分はそのアプリ固有に閉じますが、その シェアを奪わんとする側は移行ツールを用意するなど 製品をさらに改善してくるでしょう。また逆に、アプリに 閉じない汎用ツールを目指す側はシンプルな申請ツールを 開発するでしょう。
申請操作ではなく、本質的な申請情報の部分に国の役割を 限定することがクライアント側に自由をもたらし、一定 ルールの下での自由競争が多様性と品質の改善を もたらします。最終的にはこのような民間がドライブする 努力こそが優れた電子国家を作るのであって、国は申請を 受け付けるプレーヤでもあるものの、基本的にはそれを 阻害しない範囲での審判に徹しなくてはなりません。
リファレンス実装に関していえば、あくまでリファレンスに とどまる(MIT X 的?)のであれば有益ですが、現状では 実提供にシフトしてしまっていること、また、実装に 傾きすぎて、本質である情報交換フォーマット・プロトコルの 制定からかけ離れていることから、現状反対です。彼らは 単なる「リファレンス」実装の表面動作に囚われすぎており、 規格制定の重要性・意義について理解しているとは 思えません。これは各省庁の責というより、e-japanという 大本の基本方針が「枠組み作り」ではなく「動かすこと」に 実質なってしまっていることが大きいかとは思いますが。
なお、ここから先は枝葉末節な技術論ですが、フォーマット対 パラメータについては、フォーマットであるべきと思います。 これらの情報の応用分野を広げるには、
HTML+CSS+Javascrip のみで署名処理ができるアプリが書けたら神。
最重要な要求仕様を満たさないと意味がないわけで。
Java Applet / ActiveX / Java WebStart / .NET ClickOnce / ネイティブアプリ
一般に実行環境が簡単に準備できそうな 選択肢はこのぐらい。他になんかある?
>入力補助機能のみをJavaScriptでというような w3mではJavaScriptが使えない。 多くの環境で使ってもらえるWebサービスではないです。
「入力『補助』機能」に JavaScript が使われるくらいなら構わないのではないでしょうか? JavaScript が実装されていない UA なら自力で入力すればすむことです。
# JavaScript が画面遷移とかに使われていて、かつ # 手動で画面遷移できるボタンだの何だのが # 画面上になければ「死ね」ですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
Webは不便だ (スコア:5, すばらしい洞察)
Java必須とかFlash必須とかActiveX必須とかはイントラ向けならありですが、多くの人が自由に使えるサービスには不向きです。特に公のものならなおさら。
WebアプリケーションはWebブラウザから使え、クライアント側のアプリケーション更新も必要なく、「多くの人が利用できる」反面、ネイティブアプリケーションに比べて制約が多く入力補助や画面の変化がスムーズでなく、UI操作をリンクとボタンのクリックのみに縛られるなど「ユーザにとって不便」です。
最初に「ユーザにとって不便」という面の認識をきちんと分かってもらってないと、不便さを克服しようとしてJavaやFlash等を持ち出してネイティブアプリ寄りなことを実現し、その代償としてWebアプリケーションとしての「多くの人が利用できる」利点を失っているのだと思う。
Re:Webは不便だ (スコア:4, すばらしい洞察)
ていうかですね、入力するシステムまで官庁が用意するのが おかしいんですよ。
国の事務関係のファイルフォーマットとその送付方法だけ 定めれば、あとは(Intuitとかみたいな)民間が使い勝手の よいアプリケーションを開発・販売するのではないか?
そこを官庁が使い勝手と品質に劣るシステムをわざわざ作って 無料化とかやるから民間のビジネスチャンスは潰すわ、 駄目システムで利用者を減らすわ、縦割り弊害でコストは かかるは電子政府をせっせと潰しているんだから世話ないと しかいいようがありません。
Re:Webは不便だ (スコア:2, すばらしい洞察)
ドメインのルート(当時internicやjpnic)は原則として定型フォーマットのメールで申請を受け付けていました。
事業者はwebform等の皮をかぶせてユーザに提供します。
そこに使いやすい事業者、使いにくい事業者等の差が出てきます。
あるいは自力で定型フォーマット書けば事業者通さずに安く上げることもできました。
現在はjpドメインの場合は必ず事業者通すようになってるので、事業者-jprs間でどのようなやり取りになっているのかはユーザには不明ですが、おそらく内部的には定型フォーマットで、皮や価格の部分で各社競争しているという構図は変わらないと思います。
Re:Webは不便だ (スコア:0)
>官庁が使い勝手と品質に劣るシステムをわざわざ作って無料化
選択の自由を認めた上で、リファレンス実装として存在するのはムダではないでしょう。
それが無いままだと、一時期のブラウザ競争みたいに民間企業の競争による独自の機能拡張を許し、
制定したフォーマットとプロトコルが形骸化する恐れがあるからです。
>民間のビジネスチャンスは潰す
民間に食い物にされて、国民が馬鹿を見る [srad.jp]という話もありますね。
望むと望まざるに関わらず、さまざまなコスト・利権が発生し、長期運用が大前提な問題だけに、
仕様設定から調達に到るまで一筋縄ではいかない難しい問題があるのでしょう。
Re:Webは不便だ (スコア:2, 参考になる)
> 制定したフォーマットとプロトコルが形骸化する恐れがあるからです。
そんなことはあり得ないでしょ。
元ACの提案は、
ユーザーインターフェース周りは民間にまかせて、
官庁の電子申請用サーバは、
・制定したプロトコルを通して
・制定したフォーマット形式のデータが届いたら
・申請を処理する
・UIの無いシステム
にしたらどうかということですから、プロトコルやフォーマットに独自の機能拡張なんかしようとしても、官庁サーバ側が受け付けてくれません。
問題が起きるとしたら、
「官庁ごとに勝手な独自拡張をして、官庁間の互換性が取れなくなる」
可能性でしょうか。
縦割りでいかにも起きそうです。
Re:Webは不便だ (スコア:0)
しかし、元AC [srad.jp]は
>国の事務関係のファイルフォーマットとその送付方法
と言ってるので、パラメータから具体的ファイル形成して転送する実装に読めました。
(流石にそんなことは無いと思いますが)PDFやDOCを郵送するとも読めます。
ローカルでの閲覧・作業を考慮すると、ファイルはローカルにも作られるでしょう。
そうなると、あるクライアントUIで表示したときに有効になる情報を動的に埋め込み、
それをもとにクライアントの優位性、差別化を計る事が可能になります。
中央で管理するサーバーが、それ
国は枠組みを作り、民間が実行を担う (スコア:4, 興味深い)
元ACですが、クライアント側で各アプリケーションが 独自に色々なことをするのははっきりいって望ましい。
例えば会計ソフトに申請機能を組み込む、CADソフトに 建築設計の審査申請機能を埋め込む、などなどです。 もちろん拡張部分はそのアプリ固有に閉じますが、その シェアを奪わんとする側は移行ツールを用意するなど 製品をさらに改善してくるでしょう。また逆に、アプリに 閉じない汎用ツールを目指す側はシンプルな申請ツールを 開発するでしょう。
申請操作ではなく、本質的な申請情報の部分に国の役割を 限定することがクライアント側に自由をもたらし、一定 ルールの下での自由競争が多様性と品質の改善を もたらします。最終的にはこのような民間がドライブする 努力こそが優れた電子国家を作るのであって、国は申請を 受け付けるプレーヤでもあるものの、基本的にはそれを 阻害しない範囲での審判に徹しなくてはなりません。
リファレンス実装に関していえば、あくまでリファレンスに とどまる(MIT X 的?)のであれば有益ですが、現状では 実提供にシフトしてしまっていること、また、実装に 傾きすぎて、本質である情報交換フォーマット・プロトコルの 制定からかけ離れていることから、現状反対です。彼らは 単なる「リファレンス」実装の表面動作に囚われすぎており、 規格制定の重要性・意義について理解しているとは 思えません。これは各省庁の責というより、e-japanという 大本の基本方針が「枠組み作り」ではなく「動かすこと」に 実質なってしまっていることが大きいかとは思いますが。
なお、ここから先は枝葉末節な技術論ですが、フォーマット対 パラメータについては、フォーマットであるべきと思います。 これらの情報の応用分野を広げるには、
Re:国は枠組みを作り、民間が実行を担う (スコア:0)
Re:Webは不便だ (スコア:1, 参考になる)
HTML+CSS+Javascrip のみで署名処理ができるアプリが書けたら神。
最重要な要求仕様を満たさないと意味がないわけで。
Java Applet / ActiveX / Java WebStart / .NET ClickOnce / ネイティブアプリ
一般に実行環境が簡単に準備できそうな 選択肢はこのぐらい。他になんかある?
Re:Webは不便だ (スコア:0)
閉じたネットワーク環境ならそれでも良いけど。
Re:Webは不便だ (スコア:1, すばらしい洞察)
Re:Webは不便だ (スコア:0)
RSA暗号をJavaScriptで書けるんだからもう少し頑張れば出来そうな気がします。
http://www.faireal.net/articles/8/01/#d40204
Re:Webは不便だ (スコア:1)
ちょっと考えてもらえればわかると思いますが、JavaScript で署名できるとしたら、サーバ自身がブラウザに署名をさせられることになってしまいます。署名はユーザ自身がある動作を行ったことを証明できないといけないので、ユーザ以外がこれをできるのであれば意味がありません。
もちろん、JavaScript(というかブラウザ自体)に電子署名を行う暗号化サービスプロバイダへのインタフェースがあればそれで済む問題だとは思いますが。
Re:Webは不便だ (スコア:0)
w3mではJavaScriptが使えない。
多くの環境で使ってもらえるWebサービスではないです。
多くのPCで使ってもらえるWebサービスならば、はじめからWindows+IEの環境想定で充分。
Re:Webは不便だ (スコア:1, すばらしい洞察)
#w3mしか使ってない人って、全Webユーザの何ppmくらい?
Re:Webは不便だ (スコア:1)
どれだけ多くのシステムに、ユーザの閲覧を必要としない
Web クライアントがあると思ってる?
ユーザが直接扱う Web ブラウザなんてのは、
Web クライアントが使われる場面のうちの、ほんの
一部でしかないよ。
# mishimaは本田透先生を熱烈に応援しています
Re:Webは不便だ (スコア:1, すばらしい洞察)
w3mはページャであるという逃げ道があるからいいけど。
Re:Webは不便だ (スコア:1)
Ajaxも、そういう風に使われていればいいんだけどね。
Re:Webは不便だ (スコア:1)
「入力『補助』機能」に JavaScript が使われるくらいなら構わないのではないでしょうか? JavaScript が実装されていない UA なら自力で入力すればすむことです。
# JavaScript が画面遷移とかに使われていて、かつ
# 手動で画面遷移できるボタンだの何だのが
# 画面上になければ「死ね」ですが。
Re:Webは不便だ (スコア:1)
ブラウザがJavaScriptを解釈できないなら普通に手入力してSubmitできればOKです
それから
環境想定でWindows+IEの組み合わせではダメですね
基本的に環境想定はW3Cの標準に沿ったブラウザ(架空のブラウザ たとえばHTML 4.01 Transitionalを完璧にサポートしたブラウザ...みたいなやつ)で、
なおかつIEでもきちんと動くという感じがよいでしょう
そうすればIEが標準にあわせてきても、既存の怪しい挙動を維持しても、きちんと動作するやつが作れるんじゃないかな?
一応標準に準拠なら他のブラウザでも動くでしょうし、完成時点で動かなくてもブラウザのバグがとれてくればそのうち動くようになると思われます
でもIEだけにあわせちゃうと....将来のIEを含めた他のブラウザでの動作が怪しくなっちゃう危険が...
Re:Webは不便だ (スコア:1)
#IE用にboxモデルだけはいじらないといけませんが。
All your base are belong to us
Re:Webは不便だ (スコア:0)
つ [Amaya] [w3.org]
#ただのうけ狙いなのでAC
Re:Webは不便だ (スコア:0)
無駄に飾るより、必要最小限にして欲しいな。
どうしても無駄に飾ってお金を浪費したいなら
それこそ各クライアント+環境専用ページでも
作って下さい。(ActiveXを利用する場合はこちら、とか)
Re:Webは不便だ (スコア:2, 参考になる)
DocomoとかDocomoとかDocomoとか。
せめてクッキーくらいは使えるようにしないと、セッションキーをURLに含むハメに遭い、セキュリティ面でも相当危ういサイト作りになってるところが多い。
その点、auは標準的な作りのページにしていれば、携帯であることを意識した作りにしていなくてもしっかり使えるのが嬉しい。
vodafoneはよくしらない…