Microsoft Office Open XMLのISO標準化プロセス、難航か? 66
ストーリー by yourCat
Office2007もう出しちゃったのに 部門より
Office2007もう出しちゃったのに 部門より
Anonymous Coward曰く、
japan.internet.comの記事によると、Microsoft Office 2007が標準ファイルフォーマットとして採用しているMicrosoft Office Open XML (OOXML) のISO標準化プロセスが難航しているようだ。
OOXMLは、OpenDocument Format (ODF) と共に最近話題を集めているオフィス文書の標準規格である。
ODFは、標準化団体OASISによる認定を受けたあと、JTC1に於ける投票を経て、ISO/IEC標準 (ISO/IEC 26300) となった。OpenOffice.orgに標準ファイルフォーマットとして採用されており、最近は各国の政府関連機関で、ODF採用の動きが広がっている。
一方、OOXMLは、標準化団体Ecmaによる標準認定ののちISOにfast trackとして提出され、現在、JTC1での審議が行われている。
JTC1による今回の審議は、JTC1参加各国による30日間の反対意見申し立て期間ののち、6ヶ月投票という手順で行われる。japan.internet.comの記事でははっきりとわからないのだが、今回はどうやら30日間の反対意見申し立て期間に、日本を含む19カ国が反対を表明したらしい。
果たしてJTC1に於けるOOXMLの6ヶ月投票は始まるのだろうか。OOXMLとODFの動向に関しては、村田真氏のブログと、同氏へのインタビュー記事が大変参考になる。
ODFは満場一致で賛成 (スコア:5, 興味深い)
これだけ読むとODFがすばらしく優れているように感じますが、実際はなんでもいいから文書フォーマットの標準化をとにかく急いで完成度を不問にした結果みたいですね。
はっきり言ってしまうと、ODFの仕様書は規格といってしまうにはいまいちなデキです。
コメントが短すぎたり、別の規格を参照する過程で解釈が分かれる部分などが散見されます。
おそらく規格どおりに作成しても互換性は保たれないので、ところどころでOpenOffice.orgの実装を参照しなければまともなオフィススイートはつくれません。
OOXMLの仕様書はサンプルを多く載せているのと外部参照を減らしているので多少はましな印象ですが、規模が巨大なためすべてを実装するのは体力がないと辛いです。
ということで、OOXMLの仕様書は私企業版にとどめておいて
ODF-OOXML間の厳密な変換方法を規格化すると少し楽しい未来になるんじゃないですか。
Re:ODFは満場一致で賛成 (スコア:5, 興味深い)
odfへの対抗として提出されたものであるという一点に収束しうると思います。
odfとほぼ類似しているooxmlの提出は、共通の基準を纏め、
各々の努力はその基準の上に構築される成果物に向けようという
standardの理念や存在理由を無視したものだと思わざるを得ません。
Re:ODFは満場一致で賛成 (スコア:1, すばらしい洞察)
> 対して、OOXMLは現時点で19カ国が反対を表明したそうです。
「標準規格を定めてみんなでそれを使おう。」
と各国がODFを(完成度の問題に目をつぶって)担いだ後で、
「標準規格をみんなで使いたいのか。よし、うちの製品の規格を公開してやるから、お前らで標準規格に認定して、それを使えや。by MS」
という流れだからねえ。心情的な問題も多少はあるんでなかろうか。
Re:ODFは満場一致で賛成 (スコア:1, すばらしい洞察)
そんなことはないと思いたいが、そうすると他の真っ当な理由があるはずで、ぜひともそのへんが知りたいところだが…
使い手としては中身が問題で、誰が作ったとかどういう経緯でできたとか、そんなことはどうでもいい。
Re:ODFは満場一致で賛成 (スコア:2, すばらしい洞察)
そういう「標準化に対する理念」を失って、企画書のフォーマットさえ整っていたら何でも追認するような団体こそ必要ないものです。
Re:ODFは満場一致で賛成 (スコア:1, すばらしい洞察)
そういう点では、デファクトスタンダードである Microsoft Office Suite のドキュメントと全く互換性の無い (いかに変換をかけても埋めようの無い差のある) ODF は経緯を気にしていないことになるように思いますが、どうなのでしょうね。そして、それを満場一致で可決した JTC1 は経緯を考えていないのでは、と。村田氏に「細かく見ていたら通る訳がない」ものと言われてしまっていますし。
とりあえずオープンなものを、ということで 1 つの仕様書内ですら整合性がまともに取れていない ODF が通ってしまっているのは、まさに「企画書の体裁さえ整っていたらなんでも追認する」状況ではないですか。OOXML に対しては前例ができたので、とりあえずまともに評議しようとしている、と。
Re:ODFは満場一致で賛成 (スコア:1, 興味深い)
それは、全く経緯を無視した指摘ですよ。その時点では、MSの文書は全くのブラックボックスだったのですから、互換性のとりようがありません。
今こういう議論ができる事自体が、JTC1の英断のおかげだと言う事を忘れてはいけませんよ。そういう意味では、意図が狙い通りに反映されている、と言えるでしょうね。
Re:ODFは満場一致で賛成 (スコア:2, 参考になる)
MS Office文書の仕様は一部が開発者向けに公開されています。
(たとえば "Rich Text Format (RTF) Specification" [microsoft.com])
ですから全くのブラックボックスとはよくある誤解です。
非公開なのはそれぞれの機能に割り振るコードとか実装に深く関係する部分です。
そうでなければOffice互換ソフトなんて一から作れるわけないでしょ。
Re:ODFは満場一致で賛成 (スコア:1, 参考になる)
ODFにお尻を叩かれてやっと動く会社ですから。
おかげで、ワードファイルが肥大化して破損した場合、
なんとかできるようなユーティリティはHTMLやtexのようには存在しません。
それに、標準化した後に独自拡張とかも考えてたりしそうですしね。
実際、外部のメーカーが互換ソフト作っても内部規格変更の度振り回されてるでしょうし。
# MARQUEE機能とか作ったら笑うけど…
Re:ODFは満場一致で賛成 (スコア:0)
ISOがOOXMLにお墨付きを与えた後で、MSが公開または非公開で独自
拡張をバシバシ入れてきたらどうなるんでしょう。
MS-Officeの圧倒的なシェアの前に、ISOは成す術なし?
もしかして振り出しにもどる?
Re:ODFは満場一致で賛成 (スコア:5, 興味深い)
日本の EPWING の例が浮かびました。(実装が先行した後、JIS X4081 として規格化されましたが、その後も仕様が拡張されています。最新の規約を入手するには、法人のみ会員になれる EPWING コンソーシアム [epwing.or.jp]に入会する必要があります。JIS の規格から得られる情報だけでは最新の EPWING タイトルを読めないことが多いので、個人が開発している EPWING ビューアは、開発者の独自解析に頼っていると聞きます)
Re:ODFは満場一致で賛成 (スコア:3, 参考になる)
>(たとえば "Rich Text Format (RTF) Specification")
>ですから全くのブラックボックスとはよくある誤解です。
まず、全てが公開されていたわけではありません。
また、RTFもどんどん仕様が進んでおり、OOoを始め他のプログラムでも最新のRTFをフォローできない状況と認識しています。
仕様を作った本人(MS)がどんどん仕様を進めてきているので、公開されていても標準にならない状況です。
(これまでのIEのHTMLの表現仕様が同様)
なにより、以前の状況でWordの書式を標準利用すれば、いつ「そのフォーマットを使うのは著作権料を請求する!」
といわれかねない状況であったと思います。
ODFが万全の規格ではなかったのは確かだと思いますが、それによりMSが標準化・公開に乗り出したのは確かだと思います。
もしかすると、MSが標準フォーマットを提案しても、再び他の規格同様MSがOfficeの仕様を変更して、
標準フォーマットよりこれの方が利用価値が高いんだよ~
などと言い出すことを心配する向きもあるのかも、などと妙な深読みなどもしてしまいます。
Re:ODFは満場一致で賛成 (スコア:1)
これはISOにも言える事だと思うのですけどね。
国コードや言語コードなどに課金? [srad.jp]という話もありましたし。
# 僕らは何を信じればいい。
Re:ODFは満場一致で賛成 (スコア:1)
この復元機能ですが、いつも感じるのは、どこまで復元されているのか、怪しくて安心して使えない、
という点です。
Word などでよくあるのが、図や表を入れて、さらにそれを float させると、次第に理解不能の挙動を示すようになる。それを何とかしようといじっているうちに落ちる。で、次に起動して、復元らしき事が行われますが、そもそも不安定な挙動を示していたものなので、何がどこまで復元されているのか、意図したように復元されているのか、良く分からない。なので、こういうことにあうと、とりあえずテキストだけ保存し直して、ファイル作り直しをします。ロスはでかいですが、疑心暗鬼で作業するよりよっぽどまし。なお、当然、図を float させようなどというお恐れ多いことは考えないようにします。これまた不便ですが、挙動不審よりマシです。
プレーンテキストでなにがうれしいかというと、テキストエディタで表示されているものがファイルの内容そのものである点です。それは低レベルなのかもしれませんが、単純で分かりやすい構造です。
というわけで、Word を使わざる得ない場合には、
と心に決めております。
なので、Word に新機能なんていりません。Word 95 あたりで十分です。
# バグだけとってね
オープンソース実装のない標準規格は画餅 (スコア:2, 興味深い)
確保して「これぞ参照実装」という地位を獲得していなければ、標準化団体よりも実装者による
支配の方が強くなってしまう。これは避けられないのではないでしょうか。
たとえば PDF は ISO で標準化されたりしているらしいですが、Adobe Acrobat という支配的な
実装が存在します。Acrobat で開けないファイルは、たとえ ISO の標準に準拠していても
世間は PDF と認めてくれないでしょう。また Acrobat で作ったファイルを表示できなければ、
PDF のレンダラーとして世間は認めてくれないでしょう。
なおかつ、オープンソースソフトウェアが持続的に成長して行くためには、実装すべき仕様は
簡潔である必要があります。複雑怪奇な仕様を、単に標準として認知させるためのアリバイとして
企業丸抱えのオープンソース実装が名目上存在する、という状況ではまずい訳です。
まず事実関係の確認を (スコア:5, 参考になる)
楠@VP, IdM, Yahoo! Japan
Re:まず事実関係の確認を (スコア:1, すばらしい洞察)
つまり、マイクロソフトは、「懸案事項」に取り組める立場ではなく、全てを「事実関係の確認」として説得しなければいけない、ということじゃないですか?保留つきの回答でも、厳しいことに変わりはないでしょう。
私も、タレコミの言い様は、あまり正確ではないと思いますけどね。
Re:まず事実関係の確認を (スコア:2, 興味深い)
超希望的な観測をしてみます。
以下の点を考慮すると、コメントに対して追従 (修正) を行い、Office 2007 を ISO で認可されたバージョンの OOXML に改訂するプロセスはありうるのではないかと考えます。
これらを組み合わせると、既に発売されている Office 2007 をユーザの負担を最小限に (Microsoft Update 程度で) ISO 標準に通過した OOXML に対応する Office 2007 へ「アップデート」していく事も可能なのではないか、と考えられます。もっとひどい方法としては、ISO OOXML 用フィルタを用意する、とか。:) (で、Word 文書が .idocx とか、先頭に i を付けて「フィルタが必要」なことを認識するとか……)
Re:まず事実関係の確認を (スコア:0)
Re:まず事実関係の確認を (スコア:1, すばらしい洞察)
Re:楠@マイクロソフト (スコア:4, おもしろおかしい)
Re:楠@マイクロソフト (スコア:2, おもしろおかしい)
そのルールはいつ標準化されましたか?
--
そんなルールが提案されたら絶対に反対を表明すると思うAC
Re:楠@マイクロソフト (スコア:1, すばらしい洞察)
なんでやねん、profile欄のリンク先見ればマイクロソフト関係者ということはわかるがそれが何か問題?
Re:楠@マイクロソフト (スコア:0)
DVD規格のよう (スコア:2, 参考になる)
DVD+Rと-R両対応ドライブが主流になったように、
ODFとOpenXMLが両方読み書きできる
ようにソフトウェアががんばることになるんでしょうね。
#japan.internet.comを見ての疑問。
#プロプライエタリなコードを含んでても
#標準化には問題はないのですか?
ODFとOpenXMLが両方読み書きできるようにがんばる (スコア:1, おもしろおかしい)
仕事を作ってくれてありがとう。 (スコア:0)
#それで金が取れればいいんだけど
#まぁどうせどこからか買ってくればいいやって思っているのでAC
Re:DVD規格のよう (スコア:1)
> ようにソフトウェアががんばることになるんでしょうね。
既にMSが、ODFとOpenXMLを相互に変換できるツールを発表 [impress.co.jp]してますよ。
ただ実際にODF->OpenXML->ODFと変換してみて、最初と最後が果たして同じになるか、
ちょっと微妙な気がします。
I'm out of my mind, but feel free to leave a comment.
うるう年の問題 (スコア:2, 興味深い)
MS-Officeは、日付のデータを、1900年1月1日からの通算で内部表現しているそうだけど、1900年が本来はそうじゃないのにうるう年(leap year)であると認識するバグを持っていて、それがずっとひきずられているらしい。
http://support.microsoft.com/default.aspx?scid=kb;ja;JP106339 [microsoft.com]
つまり、1900年3月1日以降において、真面目に1900年1月1日から積算した日付と、MS-Excel内部の日付には1日のズレがある(通算日数と年月日の対応関係では、Excelは自動的に-1するようになっているから、見掛け上は問題にはなっていないだけ...そのかわり、1900年2月28日以前の対応がズレているけどそれは放置されている)。で、さらにすごいのが、このバグ(仕様?)が、新しいOpenXMLフォーマットの仕様にまで入っていること。つまりMicrosoft社は、自社のMS-Excelで糊塗しているバグを直さず、かわりにそれを「オープンな仕様」にしようとしている。
こんな仕様、信用できますか?人類の歴史は、MS-ExcelもしくはOpenXMLフォーマットで記載されるものはすべて、「1日だけずれるのかどうか?」というambiguityを抱えることになる。日米開戦の日付が日付変更線のあちらとこちらで違うというレベルの話でなく、下手したら、ほんとに1日ずれちまうんだよ。それでいいの?
http://www.robweir.com/blog/2006/10/leap-back.html [robweir.com]
Re:うるう年の問題 (スコア:2, 興味深い)
Microsoft Excelの元プログラムマネージャJoel Spolsky氏の「 はじめてのBillGレビューのこと [joelonsoftware.com]」をどうぞ。
Excel ← Lotus ← VisiCalc? (スコア:1, おもしろおかしい)
http://www.robweir.com/blog/2006/10/leap-back.html#1114765182089629266 [robweir.com]
#1108545は参照したという記事を本当にちゃんと読んで投降しているのだろうか?
しかしこのコメントはもっと面白いな。
http://www.robweir.com/blog/2006/10/leap-back.html#3022317665572988689 [robweir.com]
Re:Excel ← Lotus ← VisiCalc? (スコア:2, 参考になる)
ご本人のサイトもあります [danbricklin.com]。VisiCalcもダウンロードできます。
※VisiCalcで検索したら、略称のDanのままの表記のサイトが多いけど、
本名はDaniel。ビルゲイツの本名がウィリアム何とかVer.3って長い名前なのと同じ。
で、Wikipediaの記事 [wikipedia.org]にあるように、
他社が思いっきりタダ乗りしていたのなら、「バグ」の槍玉にあげる権利はないよなと思います。
Re:うるう年の問題 (スコア:1, 参考になる)
それをまだ入れるかどうかというのは議論の余地が有るかもしれないですけど。
joel on software MSの後方互換性 (スコア:1)
http://japanese.joelonsoftware.com/Articles/StrategyLetterII.html [joelonsoftware.com]
>Microsoftはそのバグを追いかけ、Windows 95にSimCityを検出するコードを追加した。
>それがSimCityが実行されているのを見つけると、それはメモリをすぐには開放しない
>特殊なモードでメモリアロケータを実行するのだ。この強迫的なまでの後方互換性
OOXMLの話も含めてここまでいくと、正しいんじゃなくてその姿勢は間違ってると言いたくなる。
Re:joel on software MSの後方互換性 (スコア:1)
その記事が論じているのは、つまるところ、「Microsoft のそのやり方はなぜ成功したか」です。元引用で最後に切られている次文章の通り。
Microsoft の流儀なら、ODF が既に普及した規格であれば、後方互換性であわせてくると思います。
ODF と OOXML はどちらも普及どころかまだ定着もしていない規格だから、Microsoft は自分が作った仕様をよかれと主張していると思います。
Re:joel on software MSの後方互換性 (スコア:1)
>自分が作った仕様をよかれ
のよかれの中に、一般規格には非常識と言える自分のバグを仕様化した、MS社内のみ有効な後方互換への強要が含まれるわけでしょ。
一般へのよかれならうるう年バグを含むハズがないよね。
あくまでMS社内へのよかれで。
もっとMSにはその非常識規格を提案する権利がある事はあるんだろうけどね。
あくまで権利の行使だけであって、一般へのよかれじゃないよね。
じゃその「バグを含んでよし、個々の実装でいちいち回避すれば」を前提として提案しちゃうような一般には不可解なMS流儀はどこから来たのか?
ちゃんとストーリーはつながりますよ。
Re:うるう年の問題 (スコア:0)
再実装の問題 (スコア:2, 興味深い)
1904年以前の事象しか扱わないプログラムなりデータベースを作っているならいいでしょうが、標準化されるってことはその規格でずっと使われるってことです。
最初に間違えた人が誰でもいいですが、これだけはっきりした間違った挙動を正式規格に入れることは止めて欲しいです。2000年問題だって、あれだけ分かりやすいルールでも結構問題になりましたよね。運用でカバーというのはこの問題では、所詮その場しのぎだと思います。
今だったら、被害は過去の資産由来のExcelファイルのわずかで済みます。最悪、コンバートするとか、気がついたら直すでもいい。100年前の日食の記録とかをExcelで管理しているとかいう人にとってはたまったものではないだろうけど、でも規格になっちゃったら、将来すべての実装者がその訳が分かんないbugを再現しなきゃいけないんです。それはいくらなんでも今後ソフトウェア技術者が払うペナルティーが大きすぎます。賛成できません。
vyama 「バグ取れワンワン」
勝手な想像ですが (スコア:1)
あえて緩い仕様にしておいてファイルとしては仕様を満たしていても、結局はMSOfficeでは読めなかったり、またはその逆だったりという状態になっているんじゃないでしょうか
「とあるDOMノードには実装者が自由に拡張アトリビュートが追加できる」とかいうゆるい仕様を用意して
実際のExcelはそこに表現上重要な情報を格納してる
とか
Re:勝手な想像ですが (スコア:2, 参考になる)
それなんて ODF? とか素で思ってしまいましたが。
とりあえず ODF 1.1 の仕様とかから拾ってみます。あくまで審議に通ったのは ODF v1.0 で、ここで見ている ODF v1.1 (2006/10/19 版: Committee Specification 1) ではありませんが。
緩さの例としてはスクリプト周り。言語の指定は以下の通り。(2.5.1 Script - Script Language)
アプリケーション依存かよ!
重さの例はスタイル周り。(2.7 Styles)
XSLT はともかく、CSS2 ってあーた…… Spec 出てから仕様に準拠する実装が出てくるまでどれだけかかっているのか、と。さらに未だに印刷周りなんて怪しいものがかなり多いでしょうに。
というか、CSS2 っていつ国際標準規格に。
仕様を読むと「The notation is inspired by the W3C XSLT 2.0 draft, see §12.3 of [XSLT2].」(14.7.10 Transliteration) とか、楽しげな文言が踊っています。インスパイアされましたか。思っても書くなと。
仕様を見て感じた率直な感想は、Relax-NG が読みたいのではなく仕様が読みたいのだからお願いだから普通に書いてください。そりゃスキーマも必要だけどさ。HTML4 Spec. くらい読みやすくしてくれとは言わないけれども。村田氏の blog にあった「あの完成度からいえば、本当なら反対がボンボン飛んでくるはず」「本文に書いてあるタグ名と、スキーマに出てくるタグ名が違う」「そういう初歩的な問題が、1つや2つじゃなく、いっぱいある」「ODFの仕様書というのはスキーマにコメントをつけた程度」というのを痛感しました。
繰り返しますが、見たのは ODF v1.0 ではなく ODF v1.1 の仕様なのでこれが規格を通ったわけではない点は留意する必要はありますが、現状のままだと、少なくとも OOXML と同じようにしっかり審議されたらこれは通らないんじゃないですかね。
Re:勝手な想像ですが (スコア:0)
これは中立的な観点に基づく真っ当で建設的な批判と言えるんでしょうか? つい最近W3C標準になったXQuery仕様の冒頭にはこんな一文があります。
Re:勝手な想像ですが (スコア:1)
XQuery の経緯と成り立ち、そして何よりも「国際標準規格」ではない点から W3C の仕様と同列には語れないと思いますよ。ISO の審議を通った HTML4 などは W3C HTML4 と全然仕様変わっているわけですし。
# まぁ、W3C HTML4 はリリース日に合わせる事が優先されて仕様内に整合性の取れていない説明がある訳ですけど。
Re:勝手な想像ですが (スコア:1)
XQuery の成立の経緯がどうでもいいというのはとても不思議ですね。引用している部分は Introduction なのですが。XQuery の概要において同系列の先行技術に触れている部分です。こうした部分は「なぜこの仕様が必要なのか」を説明する部分でもあります。これはまさに成立の経緯に当たりますが、どうでもいいのでしょうか?
対して ODF v1.1 の場合は機能説明の部分で「XSLT 2.0 に発想を得た」と書いているわけで、何を見て思いついたか、なんて話は先行技術に関する言及とは全然話が違います。公開された規格書上に書かれていたら「これ書いた奴誰だよ。文章 1 つまともに書けないのか」と思われて当然でしょう。
Re:勝手な想像ですが (スコア:1)
もしも剽窃だとか盗用だとかいう議論があれば、いつでも受けて立ちますよ、という表明です。
(「インスパイアされた」と予め断っておかなかったためにトラブルになった表現例は最近多い。)
それを読み取れずに「文章ひとつまともに書けない」と非難するのは、きわめて幼稚です。
Re:勝手な想像ですが (スコア:1)
元仕様文章を見てみるのがよろしいかと。コンテキストまで含めて考慮するにはそれが一番だと思いますので。
「この機能は○○を元にしている」などといった記述があるのはなんら問題ないと思いますが、それも書く場所次第という事はお分かりでしょうから。
Re:勝手な想像ですが (スコア:1)
コンテキストを含めて考慮すれば何か違った結論になる、という奇妙な自信の裏付けは見つかりません。
Re:勝手な想像ですが (スコア:0)
スキーマの標準化よりもスキーマ拡張方法の標準化に注力すべきではないかと。
たとえばジャストシステムのxfyのようにそのような使用方法を念頭に置いたXML編集環境の実装は既に有るわけですし。
本当に反対なの? (スコア:1)
といわれたら、
「とりあえずもう少し検討する時間をくれ」
というと思うが
そういうのも入ってんじゃないの?
仕様書がどちらも「使えない」のは判った (スコア:1)
#実はOpenOfficeのライセンスで上記のようなことが許されるか知らないんだけど。
ボソ (スコア:0)