パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

英国政府、公文書のフォーマットとしてPDF/AやHTML、ODFの採用を決定」記事へのコメント

  • by Anonymous Coward

    Acrobatを採用してOOXMLを外すのか。。
    政治って嫌だなあ。

    • Re: (スコア:5, 参考になる)

      by Anonymous Coward

      OOXML: 何が問題なのか [ibm.com]

      OOXML に関しては、いくつかの技術的なクレームが上がっています。そうしたクレームはどれも、煎じ詰めれば同じ基本的な内容に行き着きます。つまり OOXML は妥当な共通交換フォーマットを規定するのではなく、バグの適合性に至るまで Microsoft Office の機能セット全体を規定しているのです。このため Microsoft Office 以外の実装者にとっては、OOXML 標準を満たすのは実情にそぐわない (そして満たすことは実際には不可能な) 大きな負担となる一方で、Microsoft が既に出荷しているものには都合良く完全に一致しています。これは大きな懸念事項です。

      • by Anonymous Coward on 2014年07月30日 11時15分 (#2648080)

        リンク先の文章が興味深かったので読んでみましたが、いくつか「うーん?」となる部分も。
        ちょっとオフトピ気味かも。

        不合理な要求
        ロケールには何を使えるのでしょう。この仕様を実装した他の任意のベンダーが使用している可能性のある、すべてのロケールの完全なリストはあるのでしょうか。また、フォント名やフォント・タイプをローカライズするために選択できる、すべての方法の完全なリストがあるのでしょうか。もし、ある熱狂的な実装者が、皆さんが実装した時点では聞いたこともなかった言語でフォント名とフォント・タイプを選択したらどうするのでしょう。

        じゃあ、どうやってローカライズ仕様決めれば満足するの?
        IBMは完全な仕様を実現出来るって事?
        それともまさか、ローカライズ自体やめろ、使うのは英語のみにしろ、っていうアホくさい事言ってるの?

        不適切な仕様
        一部の Microsoft Office 文書は VML と呼ばれるベクトル・マークアップ言語による図を使用するため、OOXML はこれらの図の保存方法を規定しています。これはつまり、OOXML を実装する場合には必ずこれらの図を読み取れるようにしなければならないことを意味します。しかし、あいにく VML による図を読み取るための実際の仕様は提供されていません。特定の項目の内部にストリングとして VML 形状が見つけられるのみです。

        これはまあ、妥当、かなぁ。
        でも、SVGの実装とVMLの実装で、そんなに苦労が変わるかな?
        まあ、MSの為だけにわざわざVMLを実装しなければならない、っていう部分にぶーたれる気持ちはすんごいわかりますが。

        固有の機能
        この機能が OOXML 仕様の中にある理由は、OOXML が文書交換のフォーマットではないためです。OOXML は、Microsoft の歴史的なバイナリー・フォーマットを注意深く、1 ビットも例外なく不等号括弧の中に複製したものなのです。

        これは仕方が無いし、どうしようも無くない? 後方互換性を無視したら、ぶーたれるのは使用者だし。
        同文章でも

        これまでに挙げた例とほとんど同じように、これらの改行ルールの仕様は何も提供されていないため、当然ながら他の誰もこの仕様を実装することはできません。実際、OOXML 標準には、これを実装しないように実装者に警告する記述まで含まれています。

        って触れられてるし、MS自身も問題を認識しているのだから、実装する人が実装せず、風化するのを待てば良い。
        ていうか、今更Word 97使ってる人なんているなら、さすがに新バージョンにする事をお勧めするべき。

        これは XML が不適切な選択肢という意味なのか
        XML の目的は、どのように文書の内容を記述したいのかを明確に表せるようにすることです。ODF の記述はまだ完全ではありませんが、少なくとも、やがて完全なものになることは十分に予測することができます。

        そんな希望的観測言われても。

        まとめ
        OOXML の仕様に、Microsoft Office のすべてのバージョンのありとあらゆる機能を含めようとしたり、一部の文書で使っている可能性のあるすべてのフラグや奇妙な動作などを含めようとしたりするのではなく、もっと小規模で最低限の、交換可能なフォーマットを作成することに焦点を絞り、そのフォーマットの中ですべてが実装可能な形で記述されたコア機能を提供することです。単にスプレッドシートのデータや式をコピーしたいだけの人達に対して、例えば Excel® の計算チェーンなど、実装による奇妙な動作を公開してはいけません。VML ライブラリーや DrawingML ライブラリー、あるいはそれらに類するものの詳細は公開してはならず、それらに言及すらしてはいけません。それよりもむしろ、まったく新しい、オープンで完全に規定された、データを記述するための方法を提供する必要があります。

        そんな無茶苦茶な。
        Officeの文章を交換可能な形にせよという圧力があって出来たのがOOXMLであって、ちょっと方法論が逆転してない?
        つまり、MSはOfficeの機能を他の競合製品に合わせてダウングレードすべきって事?
        それとも、コンパクトなXML仕様+クローズドなバイナリによる独自仕様の合わせ技にせよって事?
        そんな事したら、また文句言うくせに。
        一応がxmlによるstringなんだから、以前の混沌としたOLEよりは何倍もマシでしょう。

        それよりもむしろ、まったく新しい、オープンで完全に規定された

        って、それ自体が矛盾してない? 既存のオープンな資産を活用せよ、ならまだしも、「まったく新しく」かつ「オープンな」仕様って、その回答は結局OOXMLになるんじゃないの?
        ECMAでもISOでも標準化されてるんだしさぁ。

        親コメント
        • by Anonymous Coward

          あと、さらに追記。

          > これまでに挙げた例とほとんど同じように、これらの改行ルールの仕様は何も提供されていないため、当然ながら他の誰もこの仕様を実装することはできません。

          旧バイナリ形式の仕様は既に公開されてるから、そもそもこの言い分自体が古いね。

アレゲは一日にしてならず -- アレゲ見習い

処理中...