パスワードを忘れた? アカウント作成
14618 story

Microsoft Office Open XMLのISO標準化プロセス、難航か? 66

ストーリー by yourCat
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の動向に関しては、村田真氏のブログと、同氏へのインタビュー記事が大変参考になる。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2007年02月11日 19時28分 (#1108371)
    対して、OOXMLは現時点で19カ国が反対を表明したそうです。

    これだけ読むとODFがすばらしく優れているように感じますが、実際はなんでもいいから文書フォーマットの標準化をとにかく急いで完成度を不問にした結果みたいですね。

    はっきり言ってしまうと、ODFの仕様書は規格といってしまうにはいまいちなデキです。
    コメントが短すぎたり、別の規格を参照する過程で解釈が分かれる部分などが散見されます。
    おそらく規格どおりに作成しても互換性は保たれないので、ところどころでOpenOffice.orgの実装を参照しなければまともなオフィススイートはつくれません。

    OOXMLの仕様書はサンプルを多く載せているのと外部参照を減らしているので多少はましな印象ですが、規模が巨大なためすべてを実装するのは体力がないと辛いです。

    ということで、OOXMLの仕様書は私企業版にとどめておいて
    ODF-OOXML間の厳密な変換方法を規格化すると少し楽しい未来になるんじゃないですか。
    • by soltiox (25610) on 2007年02月11日 20時01分 (#1108390) 日記
      ooxmlの問題点は、規模の巨大さでも、規格としての完成度でもなく、
      odfへの対抗として提出されたものであるという一点に収束しうると思います。

      odfとほぼ類似しているooxmlの提出は、共通の基準を纏め、
      各々の努力はその基準の上に構築される成果物に向けようという
      standardの理念や存在理由を無視したものだと思わざるを得ません。
      親コメント
    • Re:ODFは満場一致で賛成 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2007年02月11日 20時12分 (#1108396)
      > ODFは満場一致で賛成
      > 対して、OOXMLは現時点で19カ国が反対を表明したそうです。

      「標準規格を定めてみんなでそれを使おう。」

      と各国がODFを(完成度の問題に目をつぶって)担いだ後で、

      「標準規格をみんなで使いたいのか。よし、うちの製品の規格を公開してやるから、お前らで標準規格に認定して、それを使えや。by MS」

      という流れだからねえ。心情的な問題も多少はあるんでなかろうか。
      親コメント
      • Re:ODFは満場一致で賛成 (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2007年02月11日 21時27分 (#1108462)
        もし、そんな心情的なことが影響するような団体なら、その団体そのものが要らない。
        そんなことはないと思いたいが、そうすると他の真っ当な理由があるはずで、ぜひともそのへんが知りたいところだが…

        使い手としては中身が問題で、誰が作ったとかどういう経緯でできたとか、そんなことはどうでもいい。
        親コメント
        • Re:ODFは満場一致で賛成 (スコア:2, すばらしい洞察)

          by Anonymous Coward on 2007年02月11日 21時48分 (#1108473)
          いや、経緯と心情はまた別の話で、経緯ってのは十分重要ですよ。後発は先発を下敷きにするのが真っ当な標準化です。一つに絞れなければ標準化の意味がないし、後から出てきたものを認めるには、それ相応の理由が必要です。

          そういう「標準化に対する理念」を失って、企画書のフォーマットさえ整っていたら何でも追認するような団体こそ必要ないものです。
          親コメント
          • Re:ODFは満場一致で賛成 (スコア:1, すばらしい洞察)

            by Stealth (5277) on 2007年02月11日 22時41分 (#1108519)

            そういう点では、デファクトスタンダードである Microsoft Office Suite のドキュメントと全く互換性の無い (いかに変換をかけても埋めようの無い差のある) ODF は経緯を気にしていないことになるように思いますが、どうなのでしょうね。そして、それを満場一致で可決した JTC1 は経緯を考えていないのでは、と。村田氏に「細かく見ていたら通る訳がない」ものと言われてしまっていますし。

            とりあえずオープンなものを、ということで 1 つの仕様書内ですら整合性がまともに取れていない ODF が通ってしまっているのは、まさに「企画書の体裁さえ整っていたらなんでも追認する」状況ではないですか。OOXML に対しては前例ができたので、とりあえずまともに評議しようとしている、と。

            親コメント
            • by Anonymous Coward on 2007年02月12日 1時06分 (#1108615)
              そういう点では、デファクトスタンダードである Microsoft Office Suite のドキュメントと全く互換性の無い (いかに変換をかけても埋めようの無い差のある) ODF は経緯を気にしていないことになるように思いますが、どうなのでしょうね。

              それは、全く経緯を無視した指摘ですよ。その時点では、MSの文書は全くのブラックボックスだったのですから、互換性のとりようがありません。

              今こういう議論ができる事自体が、JTC1の英断のおかげだと言う事を忘れてはいけませんよ。そういう意味では、意図が狙い通りに反映されている、と言えるでしょうね。
              親コメント
              • by Anonymous Coward on 2007年02月12日 7時45分 (#1108681)
                その時点では、MSの文書は全くのブラックボックスだったのですから、互換性のとりようがありません。

                MS Office文書の仕様は一部が開発者向けに公開されています。
                (たとえば "Rich Text Format (RTF) Specification" [microsoft.com])
                ですから全くのブラックボックスとはよくある誤解です。

                非公開なのはそれぞれの機能に割り振るコードとか実装に深く関係する部分です。
                そうでなければOffice互換ソフトなんて一から作れるわけないでしょ。

                親コメント
              • by Anonymous Coward on 2007年02月12日 8時17分 (#1108686)
                だからその、実装に深く関係する部分、が公開されないのが困るんでしょうが…
                ODFにお尻を叩かれてやっと動く会社ですから。
                おかげで、ワードファイルが肥大化して破損した場合、
                なんとかできるようなユーティリティはHTMLやtexのようには存在しません。

                それに、標準化した後に独自拡張とかも考えてたりしそうですしね。
                実際、外部のメーカーが互換ソフト作っても内部規格変更の度振り回されてるでしょうし。

                # MARQUEE機能とか作ったら笑うけど…
                親コメント
              • >それに、標準化した後に独自拡張とかも考えてたりしそうですしね。

                ISOがOOXMLにお墨付きを与えた後で、MSが公開または非公開で独自
                拡張をバシバシ入れてきたらどうなるんでしょう。
                MS-Officeの圧倒的なシェアの前に、ISOは成す術なし?
                もしかして振り出しにもどる?
              • by nomnom (26419) on 2007年02月12日 12時02分 (#1108745) 日記
                ISO 規格より実装が優先されるだけのことではないでしょうか。

                日本の EPWING の例が浮かびました。(実装が先行した後、JIS X4081 として規格化されましたが、その後も仕様が拡張されています。最新の規約を入手するには、法人のみ会員になれる EPWING コンソーシアム [epwing.or.jp]に入会する必要があります。JIS の規格から得られる情報だけでは最新の EPWING タイトルを読めないことが多いので、個人が開発している EPWING ビューアは、開発者の独自解析に頼っていると聞きます)
                親コメント
              • by shiragaoyadi (27158) on 2007年02月12日 22時27分 (#1108959)
                >MS Office文書の仕様は一部が開発者向けに公開されています。
                >(たとえば "Rich Text Format (RTF) Specification")
                >ですから全くのブラックボックスとはよくある誤解です。

                まず、全てが公開されていたわけではありません。
                また、RTFもどんどん仕様が進んでおり、OOoを始め他のプログラムでも最新のRTFをフォローできない状況と認識しています。
                仕様を作った本人(MS)がどんどん仕様を進めてきているので、公開されていても標準にならない状況です。
                (これまでのIEのHTMLの表現仕様が同様)

                なにより、以前の状況でWordの書式を標準利用すれば、いつ「そのフォーマットを使うのは著作権料を請求する!」
                といわれかねない状況であったと思います。

                ODFが万全の規格ではなかったのは確かだと思いますが、それによりMSが標準化・公開に乗り出したのは確かだと思います。

                もしかすると、MSが標準フォーマットを提案しても、再び他の規格同様MSがOfficeの仕様を変更して、
                標準フォーマットよりこれの方が利用価値が高いんだよ~
                などと言い出すことを心配する向きもあるのかも、などと妙な深読みなどもしてしまいます。
                親コメント
              • by of (17899) on 2007年02月13日 1時11分 (#1109005) 日記

                なにより、以前の状況でWordの書式を標準利用すれば、いつ「そのフォーマットを使うのは著作権料を請求する!」
                といわれかねない状況であったと思います。

                これはISOにも言える事だと思うのですけどね。
                国コードや言語コードなどに課金? [srad.jp]という話もありましたし。

                # 僕らは何を信じればいい。
                親コメント
              • by USH (8040) on 2007年02月13日 1時18分 (#1109007) 日記

                まず、破損したファイルの修復機能であればMS OfficeにもOpenOffice.orgにも最初から組み込まれています。試してみてはいかがでしょうか。
                少しずつ改良されていますので、昔壊してしまったファイルも読めるようになっているかもしれません。

                この復元機能ですが、いつも感じるのは、どこまで復元されているのか、怪しくて安心して使えない、
                という点です。

                Word などでよくあるのが、図や表を入れて、さらにそれを float させると、次第に理解不能の挙動を示すようになる。それを何とかしようといじっているうちに落ちる。で、次に起動して、復元らしき事が行われますが、そもそも不安定な挙動を示していたものなので、何がどこまで復元されているのか、意図したように復元されているのか、良く分からない。なので、こういうことにあうと、とりあえずテキストだけ保存し直して、ファイル作り直しをします。ロスはでかいですが、疑心暗鬼で作業するよりよっぽどまし。なお、当然、図を float させようなどというお恐れ多いことは考えないようにします。これまた不便ですが、挙動不審よりマシです。

                プレーンテキストでなにがうれしいかというと、テキストエディタで表示されているものがファイルの内容そのものである点です。それは低レベルなのかもしれませんが、単純で分かりやすい構造です。

                というわけで、Word を使わざる得ない場合には、
                • Word の(便利なのかもしれないが)変な機能はできるだけ使わない
                • 不幸にもクラッシュした場合には、テキストだけサルベージ

                と心に決めております。

                なので、Word に新機能なんていりません。Word 95 あたりで十分です。
                # バグだけとってね

                親コメント
              • 仕様が ISO などで標準化されているだけでなく、オープンソース実装がある程度のシェアを
                確保して「これぞ参照実装」という地位を獲得していなければ、標準化団体よりも実装者による
                支配の方が強くなってしまう。これは避けられないのではないでしょうか。

                たとえば PDF は ISO で標準化されたりしているらしいですが、Adobe Acrobat という支配的な
                実装が存在します。Acrobat で開けないファイルは、たとえ ISO の標準に準拠していても
                世間は PDF と認めてくれないでしょう。また Acrobat で作ったファイルを表示できなければ、
                PDF のレンダラーとして世間は認めてくれないでしょう。

                なおかつ、オープンソースソフトウェアが持続的に成長して行くためには、実装すべき仕様は
                簡潔である必要があります。複雑怪奇な仕様を、単に標準として認知させるためのアリバイとして
                企業丸抱えのオープンソース実装が名目上存在する、という状況ではまずい訳です。
                親コメント
  • Jason [msdn.com]やBrian [msdn.com]がblogで詳しくコメントしています.確かに日本を含む19ヶ国からコメントがありましたが,これは反対だけでなく懸案事項や事実関係の確認などもカウントされています.contradiction phaseで可決されたので,ECMA TC45からのコメントに対する回答とフィードバックを経て,5ヶ月間のtechnical reviewがはじまります. 楠@マイクロソフト
    --
    楠@VP, IdM, Yahoo! Japan
    • by Anonymous Coward on 2007年02月11日 20時46分 (#1108429)
      村田氏も言っていますが、企業側の論理でいくと、それらのフィードバックをまともに検討するのは難しいんじゃないか、ってのがありますよね。既に製品化されている以上、「こっちの方がいいんじゃないか」といわれても、はい、そうです、とは言い辛い状況だと思います。仮にリソースが十分だったとして、次期バージョンで、「直して」しまうと、互換性でユーザーが混乱するのは分かりきっているので…。

      つまり、マイクロソフトは、「懸案事項」に取り組める立場ではなく、全てを「事実関係の確認」として説得しなければいけない、ということじゃないですか?保留つきの回答でも、厳しいことに変わりはないでしょう。

      私も、タレコミの言い様は、あまり正確ではないと思いますけどね。
      親コメント
      • by Stealth (5277) on 2007年02月11日 22時52分 (#1108525)

        超希望的な観測をしてみます。

        以下の点を考慮すると、コメントに対して追従 (修正) を行い、Office 2007 を ISO で認可されたバージョンの OOXML に改訂するプロセスはありうるのではないかと考えます。

        • Office 2007 はベータ版を公開してレビューしてもらっていましたが、このバージョンで作成された文書は製品版で読み込むと「前のバージョンで作成された文書」と警告してきます。つまり、Office 2007 間でもバージョン認識は可能なのではないか、という点。
        • Office 2007 の文書ファイルは単なる zipped XML であることから、XSLT なりで変換を掛けることでまがりなりにも過去の文書をそのまま読み込んで現行スキーマに適合する形に変換することも可能である点。
        • Microsoft Update などを通じて「重要な更新」として配布することで、既に出ている製品をアップデート可能である点。

        これらを組み合わせると、既に発売されている Office 2007 をユーザの負担を最小限に (Microsoft Update 程度で) ISO 標準に通過した OOXML に対応する Office 2007 へ「アップデート」していく事も可能なのではないか、と考えられます。もっとひどい方法としては、ISO OOXML 用フィルタを用意する、とか。:) (で、Word 文書が .idocx とか、先頭に i を付けて「フィルタが必要」なことを認識するとか……)

        親コメント
    • で、ブロガーにWikipediaを書き換えさせた際、金銭のオファーもあったのは事実なんですよね?
  • DVD規格のよう (スコア:2, 参考になる)

    by Anonymous Coward on 2007年02月11日 19時33分 (#1108372)
    標準化が少々遅れようが、Office 2007が出ちゃった以上、
    DVD+Rと-R両対応ドライブが主流になったように、
    ODFとOpenXMLが両方読み書きできる
    ようにソフトウェアががんばることになるんでしょうね。

    #japan.internet.comを見ての疑問。
    #プロプライエタリなコードを含んでても
    #標準化には問題はないのですか?
  • by Anonymous Coward on 2007年02月11日 23時25分 (#1108545)
    既出かもしれないけど、http://www.grokdoc.net/index.php/EOOXML_objections [grokdoc.net]をちょっと読んだら衝撃的なことが。

    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]

    • by Anonymous Coward on 2007年02月12日 0時57分 (#1108607)

      MS-Officeは、日付のデータを、1900年1月1日からの通算で内部表現しているそうだけど、1900年が本来はそうじゃないのにうるう年(leap year)であると認識するバグを持っていて、それがずっとひきずられているらしい。

      Microsoft Excelの元プログラムマネージャJoel Spolsky氏の「 はじめてのBillGレビューのこと [joelonsoftware.com]」をどうぞ。

      1900年はうるう年ではない。
      「これはExcelのバグだ!」 私は興奮した。
      「実際はそういうわけじゃない」とエドが言った。「Lotus 123のワークシートをインポートできるようにするために、そうする必要があったんだ」
      「じゃあ、Lotus 123のバグってこと?」
      「そう。だけどおそらくは意図的なものだ。Lotusは640Kのメモリに詰め込む必要があった。これはあんまり大きなものじゃない。 1900年を無視すれば、与えられた年がうるう年かどうか判定するのは右端の2ビットが0かどうか見るだけで済む。そのほうがずっと早くて簡単だ。たぶん Lotusの連中ははるか昔のふた月が間違っていたところで問題にはならないと考えたんだろう。一方でBasicの連中は、そのふた月にこだわってエポックを1日ずらしたんだ」
      「あーっ!」私は声を漏らした。そして「1904年から計算する」というチェックボックスがオプションダイアログについている理由を知ったのだ。
      その翌日がBillGレビューの日だった。

      親コメント
    • by Anonymous Coward on 2007年02月11日 23時38分 (#1108557)
      そもそもそれは1-2-3のバグ [fujistaff.com]に由来するので、「過去の1-2-3シートを変換してきたシート」の動作を保証する為に必要だったものです。

      それをまだ入れるかどうかというのは議論の余地が有るかもしれないですけど。
      親コメント
      • なんか凄いよね。
        http://japanese.joelonsoftware.com/Articles/StrategyLetterII.html [joelonsoftware.com]
        >Microsoftはそのバグを追いかけ、Windows 95にSimCityを検出するコードを追加した。
        >それがSimCityが実行されているのを見つけると、それはメモリをすぐには開放しない
        >特殊なモードでメモリアロケータを実行するのだ。この強迫的なまでの後方互換性

        OOXMLの話も含めてここまでいくと、正しいんじゃなくてその姿勢は間違ってると言いたくなる。
        親コメント
        • それは、このストーリーの話題で取り上げるのに適切な例でしょうか?
          その記事が論じているのは、つまるところ、「Microsoft のそのやり方はなぜ成功したか」です。元引用で最後に切られている次文章の通り。

          この強迫的なまでの後方互換性が人々にWindows 95にアップグレードしたいと思わせたのだ。

          Microsoft の流儀なら、ODF が既に普及した規格であれば、後方互換性であわせてくると思います。
          ODF と OOXML はどちらも普及どころかまだ定着もしていない規格だから、Microsoft は自分が作った仕様をよかれと主張していると思います。
          親コメント
          • いや、
            >自分が作った仕様をよかれ
            のよかれの中に、一般規格には非常識と言える自分のバグを仕様化した、MS社内のみ有効な後方互換への強要が含まれるわけでしょ。
            一般へのよかれならうるう年バグを含むハズがないよね。
            あくまでMS社内へのよかれで。
            もっとMSにはその非常識規格を提案する権利がある事はあるんだろうけどね。
            あくまで権利の行使だけであって、一般へのよかれじゃないよね。
            じゃその「バグを含んでよし、個々の実装でいちいち回避すれば」を前提として提案しちゃうような一般には不可解なMS流儀はどこから来たのか?
            ちゃんとストーリーはつながりますよ。
            親コメント
    • by Anonymous Coward
      人類の歴史
      大げさですね。あなたにとっての人類の歴史とは1900年以降なのですか? #1108557 や #1108607 の情報を読めば、Excel は 1900年以前を日付データとして扱えず、「1904年から計算」すれば正しく計算するのだから、そうした制限を認識して扱うのが望ましい、運用の問題だと思うけど。
      • by vyama (6377) on 2007年02月12日 20時15分 (#1108928) ホームページ 日記

        1904年以前の事象しか扱わないプログラムなりデータベースを作っているならいいでしょうが、標準化されるってことはその規格でずっと使われるってことです。

        最初に間違えた人が誰でもいいですが、これだけはっきりした間違った挙動を正式規格に入れることは止めて欲しいです。2000年問題だって、あれだけ分かりやすいルールでも結構問題になりましたよね。運用でカバーというのはこの問題では、所詮その場しのぎだと思います。

        今だったら、被害は過去の資産由来のExcelファイルのわずかで済みます。最悪、コンバートするとか、気がついたら直すでもいい。100年前の日食の記録とかをExcelで管理しているとかいう人にとってはたまったものではないだろうけど、でも規格になっちゃったら、将来すべての実装者がその訳が分かんないbugを再現しなきゃいけないんです。それはいくらなんでも今後ソフトウェア技術者が払うペナルティーが大きすぎます。賛成できません。

        --
        vyama 「バグ取れワンワン」
        親コメント
  • 規格自体が巨大でテストのしようが無いというのも有ると思いますし
    あえて緩い仕様にしておいてファイルとしては仕様を満たしていても、結局はMSOfficeでは読めなかったり、またはその逆だったりという状態になっているんじゃないでしょうか

    「とあるDOMノードには実装者が自由に拡張アトリビュートが追加できる」とかいうゆるい仕様を用意して
    実際のExcelはそこに表現上重要な情報を格納してる

    とか

    • by Stealth (5277) on 2007年02月12日 0時03分 (#1108577)

      それなんて ODF? とか素で思ってしまいましたが。

      とりあえず ODF 1.1 の仕様とかから拾ってみます。あくまで審議に通ったのは ODF v1.0 で、ここで見ている ODF v1.1 (2006/10/19 版: Committee Specification 1) ではありませんが。

      緩さの例としてはスクリプト周り。言語の指定は以下の通り。(2.5.1 Script - Script Language)

      The attribute script:language specifies the language of the script by its name. Since script language names are application specific, the name should be preceded by a namespace prefix.

      アプリケーション依存かよ!

      重さの例はスタイル周り。(2.7 Styles)

      This type of style information differs from [CSS2] or [XSLT] style sheets that are used to display a document. An additional style sheet for CSS, XSLT, and so on, is required to display a document in OpenDocument format on a certain device. This style sheet must take into account the styles in the document as well as the requirements and capabilities of the output device. The ideal case is that this style sheet depends on the output device only.

      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 と同じようにしっかり審議されたらこれは通らないんじゃないですかね。

      親コメント
      • 仕様を読むと「The notation is inspired by the W3C XSLT 2.0 draft, see §12.3 of [XSLT2].」(14.7.10 Transliteration) とか、楽しげな文言が踊っています。インスパイアされましたか。思っても書くなと。

        これは中立的な観点に基づく真っ当で建設的な批判と言えるんでしょうか? つい最近W3C標準になったXQuery仕様の冒頭にはこんな一文があります。

        XQuery is designed to meet the first of these requirements. XQuery is derived from an XML query language called Quilt [Quilt], which in turn borrowed features from several other languages, including XPath 1.0 [XPath 1.0], XQL [X

        • by Stealth (5277) on 2007年02月12日 12時00分 (#1108744)

          XQuery の経緯と成り立ち、そして何よりも「国際標準規格」ではない点から W3C の仕様と同列には語れないと思いますよ。ISO の審議を通った HTML4 などは W3C HTML4 と全然仕様変わっているわけですし。

          # まぁ、W3C HTML4 はリリース日に合わせる事が優先されて仕様内に整合性の取れていない説明がある訳ですけど。

          親コメント
    • そもそもXMLを使用するからには、企業であれユーザーであれ、自由に文書ファイルフォーマットを拡張できるというのが有るべき姿なのかもしれません。
      スキーマの標準化よりもスキーマ拡張方法の標準化に注力すべきではないかと。
      たとえばジャストシステムのxfyのようにそのような使用方法を念頭に置いたXML編集環境の実装は既に有るわけですし。
  • by bero (5057) on 2007年02月11日 22時20分 (#1108499) 日記
    「30日以内にyesかnoか答えろ」
    といわれたら、
    「とりあえずもう少し検討する時間をくれ」
    というと思うが

    そういうのも入ってんじゃないの?
  • 実装がオープンソースなOpenOfficeであればエンジン部分なり全体なりコピるなり改造なりして売っていいわけだけど、MS-Officeは結局1社独占にしかなりえないんだから、標準の意味が無いんじゃないかと妄想

    #実はOpenOfficeのライセンスで上記のようなことが許されるか知らないんだけど。
  • by Anonymous Coward on 2007年02月11日 18時03分 (#1108295)
    標準化すると税金が安くなると思うけど
typodupeerror

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

読み込み中...