村田真のXMLブログ
日本人で唯一W3CのXMLワーキンググループに参加しXMLの標準化プロセスに携わったXMLの生みの親、村田真さんのブログです。
OOXMLとODF アーカイブ
解説：Open Document Formatの標準化について
この記事は、社団法人 情報処理学会 情報規格調査会のNews Letterのために執筆したものであり、Webでもすでに掲載されている。許可を得て、ここに転載する。
ワードプロセッサやオフィスソフトは広く普及して久しい．これらの間で文書を交換するために文書フォーマットを標準化することが1980年代から試みられてきた．しかし，ハイパーテキストのフォーマットであるHTMLを除いて，文書フォーマットの標準化は失敗を繰り返してきた．例えば，ODA (ISO/IEC 8613)は普及せず，まもなく廃止される見込みである．SGML(ISO 8879)は，マニュアルなどには用いられたが，ワードプロセッサやオフィスソフトの間での文書交換には用いられていない．
ところが，Open Document Format(ODF)がOASISによって制定されるに及んで，状況は変わってきた．ODFに対抗して，マイクロソフト社はOffice Open XML(OOXML)をEcmaに提出している．両者の競合関係は，メディアでもよく取り上げられるようになっている．
以前の試みと比べると，ODFを取り巻く状況は以下の点で大きく異なる．
実装先行
ODFは，Open Officeというオフィスソフトの文書フォーマットが元になっている．つまり，ODFでは，仕様よりまず実装が先に存在した．一方，以前の試みでは，本格的な実装が現れずに終わることが多かった．
企業の利害
マイクロソフト社によるオフィス製品の独占状態に対抗することが，ODFを推進する側（サンマイクロシステムズ社やIBM社など）の目的であることは間違いない．以前の試みは，どの企業にとっても中立的な仕様を目指したが，その分だけエネルギーに欠ける憾みがあった．
囲い込みを嫌うユーザ
ワードプロセッサやオフィスソフトの利用者は，以前とは比べ物にならないほど多い．その中には，特定の製品に囲い込まれることを嫌う利用者もいる．とくに，国民に分け隔てなく情報を公開する義務をもつ電子政府は，文書フォーマットの標準を求めるようになってきた．マサーチュセッツ州がODFを採用することを打ち出したことが，ODFが注目される大きな契機となった．
ODFの標準化の道筋を簡単に振り返る．もともと，ODFはサンマイクロシステムズ社から，2002年12月に標準化団体 OASISに提案された．OASISのOpen Document Technical Committeeにおいて，ODF 1.0が制定され，2005年5月にOASIS規格となった．
OASISは，ISO/IEC JTC 1によってPAS Submitterとして承認されているためPAS手続が利用できる．ODF 1.0は，PAS手続によって2005年11月にJTC 1に提出され，ISO/IEC DIS 26300となった．JTC 1はDIS 26300を6ヶ月投票に付すとともに，SC 34に割り当てた．この投票ではすべての国が賛成であったため，コメント審議ミーティングを開催せずにISO/IEC規格となることが，2000年6月の SC 34ソウル会議で決定した．今後は，PAS SubmitterであるOASISがコメント処置文書を作成し，最終的なテキストを準備する予定である．
DIS投票において，すべての国が賛成投票をしたのは，ベンダ固有の閉ざされた文書フォーマットからオープンな文書フォーマットへの動きを支援するためであると筆者は思う．ここで言うオープンとは，公開された場で議論され，決定権が非営利の委員会にあり，RAND以外の知的所有権が見つかっていないことを意味する．ODFは，オープンな文書フォーマットであることは衆目が一致するが，決して完璧な仕様ではない．普通なら，技術的なコメントをつけて反対し，コメントが受け入れられれば賛成に回るとする国が現れるところである．
ODFが普及するかどうかはまだ明らかではない．現在，ODFの対抗馬として，Office Open XML(OOXML)がEcmaにおいて審議されている．これはマイクロソフト社がEcmaに提案したものが元になっている．Ecmaは，Office Open XMLをEcma標準とし，2006年12月にはJTC 1に迅速化手続きによって提出する予定である．
しかし，ODFの出現によって，オープンな文書フォーマットへの動きは決定的なものになったと考えられる．SC 34ソウル会議でも，Ecmaの代表は，Office Open XMLがオープンな文書フォーマットであることをしきりに主張していた．
OOXML が6ヶ月投票に付されたとき，日本として賛成するのか反対するのかは決まっていない．しかし，オープンな文書フォーマットが，日本国内の利用者や生産者にとっての利益であることは疑いない．まず必要なのは，OOXMLがオープンであるかどうかをきちんと確かめることだろう．
ODFもまだ完成したわけではなく，アクセシビリティなどの課題を数多く残している．今後もOASISで拡張され，JTC 1へのPAS Submissionによって再度投票に付されるものと思われる．
なお，ODFはJIS化を予定しており，2006年7月から原案委員会が活動を開始する予定である．
参考資料へのポインタ
http://en.wikipedia.org/wiki/OpenDocument
http://en.wikipedia.org/wiki/Open_format
http://en.wikipedia.org/wiki/Open_standard
http://www.consortiuminfo.org/standardsblog/
http://www.oasis-open.org/committees/office/
投稿者: 村田 真 日時: 2006.12.10 | パーマリンク | コメント (0) | トラックバック (1)
OOXMLの審議への参加希望か？
ISO/IEC JTC1 SC34に参加する国が急増している（参加国のリスト）。SC34は閑古鳥が鳴いていたが、P-memberが急に増えた。
原因ははっきりしないが、一つの可能性として考えられるのが、OOXMLの審議への参加である。OOXMLが、ISO/IECにfast-track手続きによって提出された場合、ほぼ間違いなくSC34に割り当てられる。JTC1のP-memberなら、投票にもコメント審議にも参加できるが、SC34のP-memberであるほうが便利なことは間違いない。
追記: 加わったのは、インド、スイス、ドイツの三カ国。
投稿者: 村田 真 日時: 2006.12.27 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLがついにISO/IECに提出された
2006年12月21日に、OOXMLがISO/IECにEcmaからfast trackによって提出された。プロジェクト番号は29500である。
これから、一ヶ月の期間で、OOXMLが既存のISOやIEC規格と矛盾していないかの検討が、JTC1によって行われる。つまり、各国は、矛盾しているという指摘をする機会がある。矛盾しているという結論が出れば、６ヵ月投票は行われない。そうでなければ、６ヵ月投票が始まる。
OOXMLとODFは矛盾しているだろうか？ これは、矛盾という言葉をどう解釈するかという問題でもある。無線などのように、方式Aのせいで方式Bがまったく動作しなくなることだけが矛盾であるという解釈もある。もちろん、すでにISO/IEC規格であるODFに、OOXMLは矛盾するという解釈もある。
追記:
JTC 1 fast track submission: Explanatory report on Office Open XML Standard
JTC 1 fast track submission: Licensing conditions that Microsoft offers for Office Open XML
投稿者: 村田 真 日時: 2007.01.03 | パーマリンク | コメント (2) | トラックバック (0)
@ITにインタービュー記事が掲載された
@ITからOOXMLのISO/IECでの標準化手続きについて、インタービューを受けた。記事は、ODFとOOXMLが今夏ISOでガチンコ勝負。
投稿者: 村田 真 日時: 2007.01.17 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLの30日間レビュー
迅速化手続き（fast-track procedure)によってISO/IEC JTC1に提出されたOOXMLのその後について書く。提出から30日間の猶予期間があって、その間に各国から既存の標準と矛盾するから取り下げるべきだという提案が可能である。
Andrew Updegroveのサイトに公開されているように20ヶ国が、この機会を利用してコメントした。各国のコメントがどのようなものかは分からない。
投稿者: 村田 真 日時: 2007.02.15 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLの30日間レビューその後
EcmaからISO/IEC JTC1にfast-track submissionされたOOXMLは、30日間レビューの間に20ヶ国からのコメントがあった。このコメントをEcma TC45は審議し、回答を作成した。回答（各国のコメントを含む）は、Computer Worldのページにある。
今後はどうなるのか私にもよく分からない。6ヵ月投票が始まりSC34へと舞台は移るのか？それとも6ヵ月投票は始まらないのか？SC34に、Ecma TC45はリエゾンレポートを送ってきた。再来週のオスロSC34会議で、より詳しい情報が得られるかも知れない。
投稿者: 村田 真 日時: 2007.03.12 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLの五ヶ月投票が開始
OOXMLの五ヶ月投票が開始されることになった。ODFと矛盾するという指摘をした国は多かったが、投票そのものは開始されることになった。長文の回答が寄せられた以上、JTC 1 SecretariatとITTF staffがこう判断したのは、驚くべきことではない。関連する記事として、Andy Undegroveの記事、Computer Worldの記事、Groklawの記事をあげておく。
今後は、五ヶ月投票に焦点が移る。最近のニュースとして、同じくfast-track submissionされたC++/CLIが、投票によってキャンセルされた。各国のコメントを満足するような解決は無理という判断によるようだ。
なお、Rick Jelliffeeの二つの記事（これとこれ）をあげておく。彼の言っていることをよく読んで冷静になろう。
投稿者: 村田 真 日時: 2007.03.18 | パーマリンク | コメント (0) | トラックバック (0)
イギリスがOOXMLの五ヶ月投票に異議を申し立てた
イギリス（正確にいうとBritish Standard Institute) が、OOXMLについての5ヵ月投票を行うというJTC1の決定に異議を申し立てたと聞いた。決定がなされたあとでのアピールであるが、手続きとして認められている。しかし、私の予想では、多少投票が遅れる程度の影響しかもたらさないだろう。イギリスも、そう思っているようだ。
投稿者: 村田 真 日時: 2007.03.28 | パーマリンク | コメント (0) | トラックバック (0)
ODFのJIS化作業
ODFはJIS化が予定されている。すでに原案を作成する委員会が発足し、翻訳作業を行っている最中である。私が委員長を勤めている。
現在、機械翻訳に得られた訳文を人手で修正（場合によっては全面書き直し）している段階である。原文の意味がとても分かりにくい（舌足らずな説明！）なため、作業は難航している。
今日はODF規格書（これはODF文書）から、図表とRELAX NGスキーマだけを残し、地の文と箇条書きをすべて削除するXSLTスタイルシートを作成した。得られるのもODF文書である。JIS原案はWord文書として作成することになるが、Open OfficeでWordへの変換は可能である。こういう作業が出来ること自体、XML化のメリットであることは間違いない。
投稿者: 村田 真 日時: 2007.04.25 | パーマリンク | コメント (3) | トラックバック (0)
ODFへのエラー報告
ODFを翻訳し、JIS原案を作成していることを前回に書いた。その過程で、ODF 1.0に数多くの誤りを発見した。本文中のタグ名とスキーマ中のタグ名が違うなど、明らかな間違いである。specifiesをspeciesと書き間違えたなどの編集上の誤りも多々ある。これほど多くの明らかな誤りがある仕様はきわめて少ないと言える。
ODFへのコメントメーリングリストのアーカイブを見れば、日本からのエラー報告が見つかる。
投稿者: 村田 真 日時: 2007.05.13 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLの国内審議
国内SC34委員会でも、OOXMLについての検討が始まっている。
最終的に投票するのは、国内SC34委員会ではなく技術委員会だ
が、国内SC34委員会での議論の結果は当然考慮されるだろう。
5/31の国内SC34委員会は、OOXMLについての議論だけで数時間を
費やす予定であり、マイクロソフト社の委員には多くの宿題を前回に
お願いしている。
しかし、ODFとの重複については、技術委員会での議論で決着す
ることになるだろう。国内SC34委員会は、技術的な検討をしっかり
しておきたいと個人的には思っている。
投稿者: 村田 真 日時: 2007.05.26 | パーマリンク | コメント (0) | トラックバック (0)
国内SC34におけるOOXML審議
国内SC34で、OOXMLにどう投票すべきかの議論が始まっていることは前の記事で書いた。議事録や資料などは、国内SC34専門委員会審議のページから入手できる。
投稿者: 村田 真 日時: 2007.06.01 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLのPart 1
Part 1を読み始めたところである。コメントしたいところはいろいろ
あるが、読めばだいたい分かるようには書いてある。実装と
照らし合わせると、まず分かるだろう（急いで言い添えておくと、
特定企業の商品がreference implementationになることは
規格として好ましいことではない）。
OPC(open packaging convention )を実装しているRELAX NGスキーマ
はほぼ正しい。少し修正すれば問題なく使える。
投稿者: 村田 真 日時: 2007.06.06 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLのスキーマ
OOXMLのスキーマには、W3C XML SchemaとRELAX NGがある。
W3C XML Schemaの版は、そのままではXerces-Jでは動作しない。同じ名前空間に対していくつかのスキーマがimportされるのがその理由らしい。同じ名前空間のスキーマすべてをincludeでまとめるスキーマを作り、それをimportすると動くという報告がある。しかし、OOXMLのすべてのルートスキーマについて試したわけではまだない。
RELAX NGの版は、いろいろ文法エラーがあり、そのままでは動作しない。現在、書き直しを行っている最中である(XSLTやRubyでプログラムを書いている）。書き直せるという感触はあるが、OOXMLのすべてのルートスキーマについて試すのはそれなりに大変である。
投稿者: 村田 真 日時: 2007.06.16 | パーマリンク | コメント (0) | トラックバック (0)
SC34の参加国がまた増えた
ISO/IEC JTC1 SC34のページにあるように、SC34の参加国がまた増えた。Cyprus, Finland, France, Kenya, Trinidad and Tobagoである。これは何を意味するのだろうか？なお、SC34のつぎの総会は京都で行われる。これにあわせて、OOXMLのコメント審議ミーティングも日本で開催される可能性がある。
投稿者: 村田 真 日時: 2007.06.18 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLへの投票私案
まだまだ、OOXML Part 1とスキーマぐらいしか見ていないので、もっとコメントすべきところは多いと思う。追加すべきことを指摘していただけるとありがたい。
なお、ODFとOOXMLの関係についてはまったく触れていない。これは、技術委員会で議論すべきことであるし、他の人より適切なコメントが私に出せるかどうかも分からない。私だけに言えることがあるとしたら、ODF規格書の品質がきわめて低いこと、過去の文書交換フォーマットはすべて無残に失敗してきたことの二つだろう。
1. Major Technical
- MSXML can handle the W3C XML Schema version of the OOXML schemas,
but we find no other validators can handle it. Reorganize it so that
it can be handled by Xerces-J and MSV at least.
- The RELAX NG version of the OOXML schemas are incorrect. Replace it
by the upcoming proposal from the Japanese member body for SC34.
- Unless the "pack" URI scheme is endorsed by IETF, it should be
dropped.
- OPC, without interleaving, should become an independent standard.
- Non-ASCII characters should be allowed as part names without relying
on %HH.
- The Custom XML Mappings Part of the SpreadsheetML should allow the
use of RELAX NG. At present, it is restricted to W3C XML Schema.
- Markup Compatibility, without PreserveELements and
PreserveAttributes, should become an independent standard.
- Application Conformance should be dropped. Better leave users make
the call. Moreover, by dropping application conformance, it becomes
obvious that implementations are allowed to ignore legacy features
and so forth.
- WordProcessingML should become a single part of the OOXML standard,
and document conformance for WordProcessingML should be clearly
defined.
- PresentationML should become a single part of this standard, and
document conformance for PresentationML should be clearly defined.
- SpreadsheetML should become a single part of this standard, and
document conformance for SpreadsheetML should be clearly defined.
- Is it possible to use VML and Math without standardizing them as
part of OOXML? Note that macros are already used without
standardization and the namespace of VML is Microsoft-specific.
- DrawingML should be devided into more than one sub-language. (See
http://www.asahi-net.or.jp/~eb2m-mrt/ooxml/dependencies.html.)
One possiblity is to introduce one sub-language per namespace. The
namespaces are:
http://schemas.openxmlformats.org/drawingml/2006/chart
http://schemas.openxmlformats.org/drawingml/2006/chartDrawing
http://schemas.openxmlformats.org/drawingml/2006/compatibility
http://schemas.openxmlformats.org/drawingml/2006/diagram
http://schemas.openxmlformats.org/drawingml/2006/lockedCanvas
http://schemas.openxmlformats.org/drawingml/2006/main
http://schemas.openxmlformats.org/drawingml/2006/picture
http://schemas.openxmlformats.org/drawingml/2006/spreadsheetDrawing
http://schemas.openxmlformats.org/drawingml/2006/wordprocessingDrawing
2. Major Editorial
- Do not use "may not".
- Do not introduce yet another definition of the word "type".
We already have at least three (XML, W3C XML Schema, and MIME).
3. Minor Technical
- Why XSLT transformation is optional? Why it is applied only on save
(not on read)?
- Are arbitrary binary data allowed as custom property parts? If so,
why is the content type fixed?
投稿者: 村田 真 日時: 2007.06.22 | パーマリンク | コメント (0) | トラックバック (0)
OOXML Part 2 (Open Packaging Conventions)についてのコメント私案
Part 2 (Open Packaging Conventions)についてのコメントです。前の
エントリーに書いたものとは一部重複しています。
1. Drop the "pack" URI scheme unless it is endorsed by IETF.
2. Publish OPC as an independent standard rather than a part of OOXML.
3. Non-ASCII characters should be allowed as part names without relying
on %HH by mandating the UTF-8 encoding. Conversion to %HH should
be avoided wherever possible, as other standard organizations have
learned (after much pain).
4. Drop interleaving since it is not used by OOXML.
5. Do not copy normative text from the W3C Recommendations
"XML-Signature Syntax and Processing".
6. Allow the use of DTDs.
7. Mention the markup compatiblity specfication only when its use
has to be disallowed.
8. The attribute name "type" and element name "Types" are very confusing.
Remember to say "MIMEType","ContentType", or "MediaType".
9. Case-insensitive comparison is archaic.
10. Whey "contentTypes" as summarized in Table 10-1 are different from
MIME content types?
11. We are not convinced if Annex H (Conformance Requirements) are
useful.
投稿者: 村田 真 日時: 2007.07.02 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLとODFの仕様書はどちらが読みやすいか
実際に、相当のページ数をあたってみて、OOXMLのほうが圧倒的に読みやすいと思う。
ODFは、まったく書き足りてないので、想像をたくましくして読んでいくしかない。しかし、読むほうに想像力を要求する規格書では困るのだ。読めども読めども自分の理解が正しいのか分からず、不安で仕方がない。時間をかけても無駄なのではないかと思うことが多い。
一方、OOXMLはページ数こそ圧倒的に多いが、少し読めば少し理解が進んだのが実感できる。この作業を続けていけば、すべてを理解することが出来るだろう。
投稿者: 村田 真 日時: 2007.07.04 | パーマリンク | コメント (1) | トラックバック (0)
またSC34参加国が増えた
P-membersとしてブルガリア、 コートジボワール, スウェーデンの三カ国、O-membersとしてギリシア、メキシコ、スリランカの三カ国である。 最新のリストを参照。
投稿者: 村田 真 日時: 2007.07.11 | パーマリンク | コメント (0) | トラックバック (0)
日本のOOXML投票
SC34専門委員会としては、No with commentsを答申することに、きのう決まった。No with commentsとは、コメントが満たされれば賛成に回るという意味であって、絶対反対という意味ではない。
ただし、日本コメントに充分満足のいく形での回答がEcmaから投票期限までにあれば、Yes with commentsにする可能性も残した答申である。
結論を出すのは技術委員会なので、最終的にNo with commentsになるかどうかはまだ分からない。
投稿者: 村田 真 日時: 2007.07.21 | パーマリンク | コメント (0) | トラックバック (0)
技術委員会でのOOXML投票についての審議
No with commentsに決まった。
投稿者: 村田 真 日時: 2007.07.31 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLの投票結果
賛成１７、反対15、棄権9だったという。賛成は（棄権を除いて数えて）2/3必要なので、
このままでは足りない。英文では、CNETの記事、Andy Updegroveの記事などがある。
しかし、ballot resolution meetingで、反対から賛成に変えることができる。正確
にいうと、これは条件付反対という投票の場合であり、無条件反対の場合は変え
られない。反対のうち、条件付反対がいくつあり、無条件反対がいくつあるかは
分からない。
5ヶ国が反対から賛成に回れば、OOXMLはISO/IEC規格になることになる。来年
2月にジュネーブで開かれるballot resolution meetingまで、このバトルは終わらない。
追記:
New York Timesの記事、Wall Street Journalの記事などが
出ている。今週中には数え切れないほど増えるだろう。
追記その2: ISOからの正式発表が出ている。
追記: いまごろ書いても仕方がないが、賛成・反対・棄権のどれも自由に変えられるらしい。
投稿者: 村田 真 日時: 2007.09.04 | パーマリンク | コメント (0) | トラックバック (1)
SC34の新メンバが与える害
SC34のメンバは急増している。これらの新メンバは、OOXMLとまったく関係のない
投票案件に対して興味をもっていないようだ。
ISO/IEC JTC1の規定では、50%以上の投票率が得られなければ、投票は
失敗するという規定がある。実際に、ある投票が、この50%ルールのために
失敗している。このままだとOOXML以外のSC34の仕事はまったくストップ
してしまうのだ。
追記(2007 10/8): その後も、50%を達成できないことによる投票失敗は
続いている。失敗したのは、RELAX NGとNVDLの正誤表の投票であり、
私としては実害を被っている。SC34及びJTC1として対策をとるべきこと
を強く主張していく。
投稿者: 村田 真 日時: 2007.09.10 | パーマリンク | コメント (1) | トラックバック (0)
Japanese vote on OOXML
Japan voted "Conditional disapproval". Japan may change the
vote to yes at the ballot resolution meeting if the Japanese
comments are resolved satisfactorily.
日本は、条件付反対を投じた。日本コメントが満足できる形で
解決されれば、日本はballot resolution meetingにおいて投票を
賛成に変えることがありうる。
Ecma TC45 appears to be considering the Japanese comments carefully.
They e-mailed to the Japanese member body for SC34 and
outlined dispositions of four major comments, which are
most significant. The proposed dispositions look quite reasonable
to me. However, the final dispositions (and the final Japanese vote)
will be made at the BRM next year.
Ecma TC45は、日本コメントを注意深く検討しているらしい。
Ecma TC45は、SC34専門委員会（日本）にメールを送り、四つの
最重要コメントをどう処置するかを大まかに示した。提案された処置は真っ当な
ものだと私は思う。しかし、最終的な処置（および日本の最終投票）は
来年のBRMの席上で決まる。
投稿者: 村田 真 日時: 2007.09.11 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLへの各国のコメント
各国のコメントが公開された。
これを調べれば、どの国が賛成に回る可能性があるか、ある程度の検討はつくだろう。
コメントの数は多いが、複数の国が完全に同じ（単語まですべて同じ）コメントを
出していることがあるので、本当にどこまで多いかはソートしてみないと分からない。
投稿者: 村田 真 日時: 2007.09.13 | パーマリンク | コメント (0) | トラックバック (0)
各国のコメントの概要
Rick Jelliffeが、OOXMLについての各国のコメントについての評を述べて
いる。日本はParrot（人から聞いたことをそのままコメントする人）ではなくて
Indie（自分で仕様を読んでコメントする人）だそうな。
投稿者: 村田 真 日時: 2007.09.17 | パーマリンク | コメント (0) | トラックバック (0)
Ballot Resolution Meetingまでの日程
OOXMLのballot resolution meetingは、来年2月25日からジュネーブで行なわれる。
1月14日までに、各国のコメントを取り入れて修正したドラフトが、Ecmaによって提出
される。今年12月には京都でEcmaのミーティングが開かれる。
BRMのとき、すべての国は投票を変更できる。つまり、現段階の賛成・反対・棄権という
投票結果はすべて覆すことが可能なのだ。
追記: 12/8からSC34総会が京都であるが、この席上ではOOXMLの審議は公式には
できない。各国が、投票結果を考慮するための期間がとられており、その期間には
公式の審議はできないことになっている（水面下ではもちろんいろいろあるだろう）。
投稿者: 村田 真 日時: 2007.09.19 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLへの反対投票が多いからといって駄目とは限らない
OOXMLは、（新参のP-memberによる多くの賛成票にもかかわらず）、判明した
投票結果では充分な賛成を得ていない。
しかし、一般に思われているほど、これはOOXMLにとって悪い状況ではない。
各国は、テクニカルなコメントが一つでもあればいったん反対し、Ballot Resolution
Meetingの審議結果を待って、最終的な投票を決めるというのが当然の手続き
なのである。一般に、真面目に読んでコメントする国は反対票を投じるものだ。
逆に、賛成が圧倒的に多いということは、真面目に読んだ国が少ない（つまり、
その規格案はどうでもいいと考えられている）と、私は受け取る。SC34にも、
そういう投票案件はいくつもある。
では、ODFのとき、なぜ反対票がなかったのか？欠陥のない仕様というわけ
ではまったくないのに？オープンなオフィス文書規格という理念に各国は賛成
したのであって、仕様書の詳細には各国とも目を瞑ったのだと思う。
投稿者: 村田 真 日時: 2007.09.29 | パーマリンク | コメント (1) | トラックバック (0)
OOXMLのBRMについて
OOXMLの投票のとき寄せられた3522のコメントから重複を除くと1030
だったという。
BRMのあとで、投票を各国は変えることができる。私は、BRMの席上で変更するの
だろうと思っていたが、BRM終了したあと30日の猶予があるそうだ。ジュネーブで
日本代表団が揉めることはないが、BRM終了後にはなにがあるだろう？
なお、ここで示した情報は、すべてBRMの議長のAlex Brownのブログによる。
投稿者: 村田 真 日時: 2007.10.26 | パーマリンク | コメント (0) | トラックバック (0)
京都でのEcmaTC45のミーティング
OOXMLのEcma TC45のミーティングが京都で12/4から12/7まで開かれる。
オブザーバとして全日参加しようと思っている。
投稿者: 村田 真 日時: 2007.11.02 | パーマリンク | コメント (0) | トラックバック (0)
AppleのOOXML実装
Ecma TC45の京都ミーティングで、AppleのOOXML実装を見せてもらった。すでに
Leopardの一部として出荷されている。OOXML文書がいくつもあるディレクトリで、
文書の先頭ページを立て続けに表示して、文書を探しやすくしている。エディタiWork
などもちゃんと動いているようだ。ああ驚いた。
Jean Paoliによると、Appleとのミーティングで、いきなりプログラマが6人出てきた
ので、Appleは本気だとつくづく思ったという。
投稿者: 村田 真 日時: 2007.12.18 | パーマリンク | コメント (0) | トラックバック (0)
ODFのdefect
ODFの翻訳のとき、数多くのエラーを発見した。それらの一部（誰が見ても明らかなもの）を、去年日本からdefect reportとして発行した。いつ、これに対する正誤表がOASIS及びISO/IECから発行されるだろうか？
投稿者: 村田 真 日時: 2008.01.07 | パーマリンク | コメント (0) | トラックバック (0)
Ecma TC45の回答
OOXMLのBRMの日が近づいてきている。現時点でのEcma TC45の
回答をすべてダウンロードしてみた。
回答はすべてPDF文書であり、全部で2839個ある。各国のコメント
に重複があれば、回答にも重複があるので、実質的には1000程度
のはずである（コメントは全部で1030)。回答は、一ページのものもあ
れば、十ページ以上になるものもある。おそらく、重複を除いても、
1000ページではきかないだろう。ききしにまさる長さである。
[追記(2008 1/23)] すべての回答をまとめたPDF文書は2293ページ
ある。重複するコメントに対する回答は、一箇所にまとめられている。
投稿者: 村田 真 日時: 2008.01.09 | パーマリンク | コメント (0) | トラックバック (0)
OOXML日本コメントへのEcma回答
Ecma回答を一日かけて精査した。まだ問題は残っているが、Ecma回答が
大変な力作であり、日本コメントを可能な限り取り入れようとしたもので
あることを認めておかないと不公平だろう。他国のコメントへの回答もページ数
から判断すると、おそらく同様だと思われる。
投稿者: 村田 真 日時: 2008.01.26 | パーマリンク | コメント (0) | トラックバック (0)
SC34における日本の地位
ODFとOOXMLは、ISO/IECにおいてはSC34に割り当てられている。このSC34において、
日本はとても重要な地位を占めている。幹事国であるばかりか、WG1の議長（私）と
WG2の議長（小町教授 ）を出している。また、SC34からEcma TC45へのliaisonも、
私が務めている。
投稿者: 村田 真 日時: 2008.01.31 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLとODFについてのBurtonレポート
OOXMLとODFの現状と将来について、Burtonグループがレポートを出した。それに対し
てODF陣営は反発している。逆に言えば、BurtonレポートはODFに対して辛い点を
つけている。
この件についてBurtonグループのblog記事から、いろいろな情報が得られる。
投稿者: 村田 真 日時: 2008.02.01 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLのBallot Resolution Meeting速報
いろいろな記事が出るだろうし、ブログにもいっぱい掲載されるだろう。そして、
そのほとんどはどうせ嘘ばかりだ。
今回のBRMは、テキストを改善する場であり、OOXMLを規格化するかどうかを
最終決定する場ではない。どう改善するかだけが今回のBRMの結果である。
この結果をもとに、各国は昨年の投票を変更することができる。どう変更するか
は、まったく各国の判断による。なお、日本コメントはほとんど受け入れられている。
Tim Brayのブログ（これとこれ）は、有益である。BRM議長のAlex Brownは
現時点で唯一の正確な記事だという。私もそう思う。ただし、What Was Good,
What Was Bad, What’s Next?はTimの意見表明であり、Alexはコメントしていない。
私が言ったことも書いていたので、Timが言ったことも書いていいだろう。彼は、
ODFの仕様書をまったく読んでいないのだそうだ。
追記: Timの記事でThe Resultに書かれていることも彼の意見表明である。私は、
DISから"somewhat better"でしかないという彼の意見に賛成しない。DISより
大幅に改善されたと思う。ただし、充分かという点は議論の
余地がある。
投稿者: 村田 真 日時: 2008.03.03 | パーマリンク | コメント (0) | トラックバック (0)
BRMに関する報道の誤り
誤りの多い記事の一例として、 「OOXML Fails to Get Majority Approval at BRM - Updated 3Xs」をあげておく。多くの記事が
これから孫引きしているので、その誤りを引き継いでいる。
"but OOXML still couldn't get a majority of the delegations to back it at the BRM"は
明らかにミスリードを狙っている。BRMでは、OOXMLに対する変更だけが議論され、
OOXMLをISO/IEC規格にするかどうかは議論の対象外である。議論の対象外なのだ
から、賛成多数を得られるわけもない。
"approve all proposed resolutions in a single vote before the end of the BRM"も誤り。
個々のresponseについて、個別に投票が行われている。ただし、各国が1000以上の
responseについて賛否を表明するのは大変なので、各国のデフォルトは何かを指定
することはできる。ある国は、デフォルトを不承認としたが、ほとんどすべてのresponse
について承認・不承認を表明している。
"refuse to vote"(投票を拒否）も誤り。"do not wish to record the vote"(投票を記録
に残したくない)をデフォルトとして選択したというのが正しい。これをデフォルトとして選択
したある国は、個別のコメントに承認・不承認を表明している。
誤りの多い記事など読む必要はない。前の記事で書いた、Tim Brayの
ブログだけ読めばよい。
投稿者: 村田 真 日時: 2008.03.04 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLについてのもう一つの記事
Tim Brayの記事のほかにも事実についてほとんど誤りのないものとして、ギリ
シャ代表団の人が書いた記事がある。私はこの記事のことをTimの新着記事で知っ
た。
Paper ballotの真実については、この記事がいちばん参考になる。ただし、
abstainとdo not wish to record our positionは、ニュアンスが違う
(abstainは消極的反対）という指摘はある。
しかし、この記事で表明されている意見（事実と意見は区別して書かれてい
る！）に私は必ずしも同意しない。たとえば、"My opinion, for example,
and many delegates agree with me, is that the Ecma responses make the
text slightly better, but though slightly better it is still abysmal."
（注: abysmalは酷いという意味）に、私は賛成しない。大幅な改善の例をいくつ
かあげる。1) non-ASCII OPC part名を許せという日本コメントを、Ecmaは完全
に受け入れてOPCを大改定した。2) IETFに通っていなかったURIスキームを落
とす又はIETFに登録せよという日本コメントも、Ecmaは完全に受け入れ、IETFに
登録した。 3) スキーマが、マイクロソフトの検証器でしか動かないという日本
コメントもEcmaは完全に受け入れ、他の検証器で動作するよう修正した。ほか
にも、大きな改善となっているdispositionは日本の分だけでもいくつかある。
もちろん、問題を隠すだけのdispositionもあるし、多少改善したに過ぎない
dispositionもある。
BRMの結果でどこまでOOXMLが改善されたかの正確な評価は、paper ballotで
通ったすべての変更を見ないと分からない。私も、これからすべての変更をもう
一度見てみるつもりである。
なお、この記事は、先に言及した 「OOXML Fails to Get Majority Approval
at BRM - Updated 3Xs」について、"overinterprets the paper ballot"だと
書いている。実に礼節をわきまえた言い方であると私は思う。
追記: 上に書いた大幅な改善のうち、1)と2)はpaper ballotで承認されている。
ギリシャ代表団は、各国のコメントを精査してはいないそうだから、きっと
気づいていないのだろう。
投稿者: 村田 真 日時: 2008.03.06 | パーマリンク | コメント (0) | トラックバック (0)
ODFのproject editorによるOOXMLについての肯定的評価
Patrick Durusauは、SC34/WG3の議長であり、ODFのproject editorの
一人でもある。彼は、ODFのほうがOOXMLより優れていると考えて
いる。
しかし、彼はOOXMLについて肯定的な評価をしている。OOXMLは
オープンな標準化プロセスを経ていると言い、OOXMLとODFの両者が
SC34で発展していくことを望み、BRMの結果を聞いてOOXMLの
承認を薦めている。
投稿者: 村田 真 日時: 2008.03.07 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLへの投票の変更状況
反対から賛成に変更したのは、私の知る限り、現在で六ヶ国である。逆に、賛成
から反対・棄権になった国が二つある。きわめて接戦であり、OOXMLが規格として
成立するかどうかは予断を許さない。結果は月曜には判明する。
訂正: 投票は締め切られた。現在七ヶ国が反対から賛成に変えた。逆に、賛成から
反対・棄権になった国が三つある。依然として、予断を許さない状況である。
訂正: 私の知る限り、反対から賛成に変えたのは八カ国(P-member)である。賛成から
棄権になったP-memberが一つ。 賛成から反対になったP-memberが一つ。賛成から
反対になったO-memberが二つ。依然として結果は分からない。
その後: OOXMLは承認されたらしい。
投稿者: 村田 真 日時: 2008.03.29 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLの承認と日本投票
OOXMLは、各国が投票内容を変更した結果、ISO/IEC規格として承認された。
もう公開してもよいと思うので、日本投票について述べる。日本は反対から
賛成に変えた。賛成することは技術委員会における投票によって決定された。
私はBRMについて技術委員会で報告し、投票は棄権した。プロフェッショナル
の誇りにかけて言うが、公正かつ的確な報告をしたつもりである。いずれ，情報
処理学会規格調査会のページで、BRM報告書は公開される。
投稿者: 村田 真 日時: 2008.03.31 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLをめぐる報道のいい加減さ
OOXMLをめぐる報道を私はほとんど信用していない。不適切な記事の
一つとして、asahi.comの記事をあげておく。
この記事を読めば、ロビー活動だけによって勝敗は決したように見えるだろう。
しかし、実際にはそうではない。確かにロビー活動は両陣営によって盛大に
行なわれたが、仕様自体の改善も空前絶後の規模で行なわれたのだ。2293
ページのEcma回答書、BRMで出された43の決議がその証拠である。イギリス、
チェコ、デンマークが賛成に変えた大きな要因は、彼らのコメントが満足のいくよう
に解決されたことである。日本コメントの多くも満足の行くように解決されている。
投稿者: 村田 真 日時: 2008.04.02 | パーマリンク | コメント (0) | トラックバック (0)
個人攻撃についてのSC34の公開書簡
ISO/IEC JTC1 SC34オスロ会議の参加者の一部は、OOXMLに関する
標準化闘争において個人攻撃があったことを指摘し、それを遺憾とする
公開書簡をまとめた。私も署名した。
多くの人には、どの陣営が誰を攻撃したのか、 よく理解できないだろう。
OOXML陣営が反対者を個人攻撃したのだろうと思うかもしれない。しかし、
実際は逆である。反OOXML陣営が、OOXMLに理解を示した人（小企業
に属する人またはまったくの個人）を攻撃したのだ。その例として、ODF陣営で
ありながらOOXMLに理解を示したPatrick Durusauに対する攻撃、
最終的に賛成したイギリスの委員であるInigo Surguyに対する攻撃を
挙げておく。BRMの議長を務めたAlex Brownなどはそこらじゅうで叩かれている。
個人攻撃を止めようというもっともな公開書簡に反発した記事が一つだけある。
NOOOXMLサイトの記事である。内容は各自でご確認されたい。
追記: チェコのHoDのJirka Kosekもひどい目にあったらしい。DIS 29500の問題点
を指摘して反対したが、それらが解決されたので賛成に回った。彼のしたこ
とはそれだけである。
投稿者: 村田 真 日時: 2008.04.13 | パーマリンク | コメント (0) | トラックバック (0)
もう一つの記事の誤り
「Open XMLへの個人攻撃は中止を」--ISOが抗議活動終結を呼びかけに
も多くの誤りがある。
まず、ノルウェーにおける抗議活動と、「個人攻撃」をやめるようにとの公開書簡との間に
はなんの関係もない。公開書簡がなにを対象としているかは、前回の記事に書いた。
これについては原文も間違っているので日本側の責任ではない。
しかし、OOXMLのISO標準化の見直しが「理論的には、万が一、ISOが投票後
1～2カ月以内に反対を表明すれば起こり得ることではある。」は翻訳上の誤り
と原文の誤りの両方がある。まず、「理論的には、万が一、投票した国が投票
後1～2カ月以内に自国の投票について反対を表明すれば起こり得ることでは
ある。」と直せば、翻訳としては正しい。しかし、原文も間違っている。万が一に
もありえない。自国の投票を撤回することを許せば、投票制度自体が機能しな
くなってしまう。それに一票差ではないので、ノルウェーの投票をカウントしなく
ても結果は同じである。
私はノルウェーの抗議活動は、各国に対する侮辱であると考えている。各国に
対し、お前には判断能力がないと言っているに等しいからである。他国のことは
知らず、日本に関する限り、意思決定プロセスになんの問題もない。日本は、
内容をきちんと把握したうえで、賛成投票することを技術委員会における投票で
決定した。技術委員会に直前になって加わったメンバーなど皆無に等しい。
投稿者: 村田 真 日時: 2008.04.17 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLのRELAX NGスキーマ
OOXMLのnormativeなスキーマはW3C XML Schemaで書かれているが、
non-normativeなスキーマとしてRELAX NGで書かれたものが存在する。
DISの時点では、Rick Jelliffeeが作成したXSLTスタイルシートによって、
W3C XML SchemaスキーマからRELAX NGスキーマが自動生成されていた。
しかし、このRELAX NGスキーマにはいろいろと問題があり、検証を通らなかった。
日本コメントとして、RELAX NGスキーマの修正を要求し、実際には私が
作業した。XSLTスタイルシートをいろいろ変更したし、rubyプログラムや新規
XSLTスタイルシートも作成した。このスキーマは、いくつかのOOXML文書に
関して正しく動作することが確認されている。
スキーマが一般に公開されるのはいつになるか分からないが、SC34の
中ではまもなく公開されるはずである。
投稿者: 村田 真 日時: 2008.04.22 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLの最終テキスト
SC34のページに、OOXMLのテキストが掲載された。一般には公開されていない。
ページ数は以下の通り。
- Part 1: 5570
- Part 2: 128
- Part 3: 46
- Part 4: 1475
スキーマは、W3C XML SchemaとRELAX NGの両方が掲載されている。
訂正: その後、ITTFの指示によってSC34のページから削除された。
投稿者: 村田 真 日時: 2008.05.04 | パーマリンク | コメント (0) | トラックバック (0)
ODFのRELAX NGスキーマの欠陥
ODFのRELAX NGスキーマをきわめて低く私は評価しているが、その
バグがいま問題になっている。OOXML expert: ODF standard is broken
を参照されたい。元ネタは、Alex Brownが書いた
ODF 1.0 and OpenOffice.org: a conformance smoke testである。
Alexの記事にもアラはあるが、ODFのRELAX NGスキーマに問題がある
という指摘はまったく正しい。実は、私は以前からこの問題を知っていた。
Jingが動かないとAlexが言ってきたとき、スキーマのバグだと教えたのは
私である。Alexはバグの修正までしてくれた。
投稿者: 村田 真 日時: 2008.05.06 | パーマリンク | コメント (0) | トラックバック (0)
南アフリカのアピール
南アフリカは、JTC1のP-memberである。その南アフリカが、
OOXMLのDIS投票について異議を申し立てた（appealという）。
文面はなぜかマレーシアのページにある。
appealの理由は以下の三つである。
1) contradictionの指摘が各国からあったのに、Ecma回答が
配られただけだった。
2) BRMの席上で、すべてのissueについてconsensusをとる
努力なしに紙投票に頼った。O-memberに投票を許したのも
おかしい。
3) BRM終了後30日でテキストが配布されていないのはおかしい。
私の理解では、一月以内にISOのTechnical Management Board (TMB)と
IECのStandardization Management Boardに提出され、そこで取り上げら
れるかどうかが決まる。取り上げられれば、conciliation panel が開かれる。
そこで何らかの案が示され、TBMとSMBによっておそらく承認される。
アピールの結果が確定するまでには半年以上かかるのではないか。確定するまで、
OOXMLがISO/IECから出版されることはない。
投稿者: 村田 真 日時: 2008.05.24 | パーマリンク | コメント (0) | トラックバック (0)
ODFとOOXMLを改良していくために
1980年代から、オフィス文書の交換フォーマットの標準化は、惨めなばかりの
失敗を繰り返してきた。最近、ODFとOOXMLが現われたことは慶賀すべきことで
ある。どちらも実装が存在している（解説：Open Document
Formatの標準化についてを参照）。
しかし、どちらも決して完璧な仕様ではないことは指摘しておかなければなら
ない。
OOXMLには、BRMで積み残しになった問題点のほかに、デザインの不統一（たと
えば、WordprocessingMLでは属性はnamespace-qualifyされているが、他の部
分ではされていない）などはいくつもある。問題点については、数多くの指摘
がなされているが、ここでは触れない。
ODFは、まったく説明の足りない仕様である。図はほとんどなく、文章はスキー
マにコメントをつけた程度のものに過ぎない。ODFのRELAX NGスキーマは、
RELAX NG DTD Compatibility(OASIS Committee Specification)に違反してい
る（a:defaultValueとID/IDREF）など数多くの問題を抱えている。ODF 1.0は、
普通のプロセスを経ていたら、ISO/IEC規格として承認されないレベルである。
なお、最後の文は、ODFのJIS原案作成委員会で、私以外の委員から出た
発言である。
完璧でなくても、やっと現われた標準である。ODFとOOXMLを改良し、まっとう
なものに育てていく必要がある。そのためには、真っ当なコメントをしなけれ
ばならない。私は、XML 1.0の成立時に大量のコメントをした。それは多少の
貢献だったと自分では思っている。コメントに応えて仕様を改善するという作
業を繰り返さなければ、仕様は決して成熟しない。
その意味で、ODFに問題点はいくらでもあるのにコメントがとても少ないのは不思議
である。ODFに賛成する人たちは、贔屓の引き倒しをしているのではないか。また、
ODF陣営も、コメントに対してもっときちんとした対処をすべきである（私のメール
を参照）。
OOXMLのDIS投票のときのコメントは玉石混交であった。その一部はBRMによっ
て解決された。しかし、まだ問題は残されている。地道な改善を続けていかな
ければならない。
OOXMLのメンテナンスについては、SC34がオスロ会議でさまざまの決定を行って
いる。私がコンビーナを勤めるOOXML Ad-hoc Group 2（これはSC34の中にある）は、
OOXMLの欠陥に関するコメントを各国および一般から集めるためのWebフォーム
を準備している。これをいつ公開できるかは、アピールの行方によって左右さ
れるが、できるだけ早く公開したいと考えている。
投稿者: 村田 真 日時: 2008.06.16 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLへの不当な批判
OOXMLへの批判には正当なものもあるが、不当なものもある。不当なものの例
として、ODFとまったく同じことをしているのにOOXMLだけが批判されるという
のがある。
その一例は、OLEに関する批判である。OOXMLはOLEを使っているからWindows
環境に依存していると批判者は言う。しかし、ODFもOLEを使っているのだ。そ
して、Windows環境以外でも動作するために、OLE以外の類似機構の使用を認め
ているという点でも、ODFとOOXMLは似ている。それなのに、なぜOOXMLだけが
批判され、ODFは批判されないのだろうか。なお、詳しくは、この記事
(OOXMLを批判する論調で書かれているが、実はODFに対する批判なのだ！）を
参照されたい。
日本における不当な批判として、ITProの記事にあるものを挙げておく。
XMLには「情報の構造が階層構造になる」という設計思想があるが， OOXMLにはこれに反する記述が多数含まれているという。このような 実装では，XMLパーサーで検出することができず，XMLパーサー利用 を前提としているソフトウエアにとっては大きな痛手になると鈴木氏は言う。
確かに、OOXMLでは、文書の論理構造とはずれた構造を、空要素によって表現
している（moveFromRangeStart空要素やmoveFromRangeEnd空要素など）。しか
し、これはODFでもまったく同様なのだ。例えば、ODFのtext:change-start空
要素とtext:change-end空要素は、論理構造とは別の階層構造を表すものに他
ならない。
論理構造と別の構造を表現することは校正支援などに必要なのだが、XMLでは
うまく行なえない。これはSGMLのころからずっと問題になってきたものであり、
数多くの人がいろんな取り組みをしてきた。日本でも「原稿校正標準マーク付
け言語(SPML)」という試みが、INSTACの電子出版技術調査研究委員会で2003年
に行われた。私も、以前に論文を書いたことがある（博士論文の材料にもし
た）。しかし、まことに残念ながら、過去10年以上の取り組みにも関わらず、
抜本的な回答は出ていない。
SGMLを利用するText Encoding Iniativesでは、Multiple Hierarchiesという
節をさいて、この問題を論じている。OOXMLとODFが採用している方法は、TEI
が導入したmilestone要素に他ならない。現時点において、milestone要素は
いちおう実用になる数少ない方法の一つである。たしかに欠点は存在するが、
これを上回る方法を誰が提案できるのだろうか。
なお、OOXMLではmilestone要素以外に、同じくTEIに由来するvirtual要素も用
いられている。milestone要素とvirtal要素は、帯に短し襷に長しなので、
併用されるのはまったく不思議ではない。
投稿者: 村田 真 日時: 2008.06.26 | パーマリンク | コメント (0) | トラックバック (0)
オフィス文書の暗号化
マイクロソフトのDavid LeBlancが、オフィス文書の暗号化について興味深い記事を書いている。
そして、マイクロソフトの[MS-OFFCRYPTO]: Office Document Cryptography Structure Specification
を参照している。
私は暗号には門外漢だが、David LeBlancの言うことを要約する。
- MS-Officeのバイナリ文書に対してマイクロソフトが提供している暗号化は弱い。 サードパーティの製品を利用すべき。
- OOXMLの暗号化はAESを用いており、大きく改善されている。
- ODF 1.1の暗号は、Blowfishに固定されている。後継者のTwofishにすべきでは
ないか。
なお、日本の電子政府推奨暗号リストを見ても、Blowfishは含まれていない。
OOXMLのPart 2（Open Packaging Convention)を見ると、確かにAESは出てくる。
正確に言うと、OPCが参照しているZIPの仕様書バージョン5.2以降がAESを許している。
残念ながらCamelliaを使う方法はない。使えるようにするには、
PKWAREに働きかけるしか方法はないだろう。
投稿者: 村田 真 日時: 2008.07.05 | パーマリンク | コメント (0) | トラックバック (0)
OOXML ad-hoc group 1 ロンドン会議
来週にロンドンで、SC34 OOXML ad-hoc group 1のロンドン会議が開かれる。
この会議は、今後のSC34におけるOOXMLのメンテナンス体制について議論
するためのミーティングである。私はWG1の議長かつAd-hoc group 2の
議長として参加する。
アピールプロセスが終了して、ISO/IEC 29500が出版された場合には、
ただちにSC34におけるOOXMLのメンテナンスが始まる。これは、
ロンドン会議の結果に基づいて行われるものと思われる。
メンテナンス初期段階において、各国から出されるOOXML拡張提案が受
け入れられる可能性は高いのではないかと私は予想している。逆に言えば、
OOXMLの拡張を提案するにはたいへん良い機会である。拡張提案をお持
ちの方は、この記事へのコメントの形でご連絡ください。
投稿者: 村田 真 日時: 2008.07.16 | パーマリンク | コメント (2) | トラックバック (0)
SC34/WG4の新設
先日のロンドン会議で、OOXML担当WGの新設を提案することが決まった。
この提案がSC34韓国会議（9月末）に承認されれば、WG4が新設される。
OOXMLはいままでWG1の担当であったため、WG1コンビーナである私が、
WG4の暫定コンビーナとなることが提案の一部として含まれる。今後、WG4の
コンビーナが正式に選ばれることになるが、そのまま私が正式コンビーナになる
ことを期待する向きもある。
投稿者: 村田 真 日時: 2008.07.31 | パーマリンク | コメント (0) | トラックバック (0)
ODF実装間の互換性とOOXML実装間の互換性
複数のODF実装間で互換性を計測し、複数のOOXML実装間でも互換性を計測したというレポートが出た。OASIS ODF TC議長のRob Weirの名前がacknowledgementにあるところを見ると、ODFについての評価はそれなりに真っ当なのだろう。
まったく別のOOXML実装の間でも互換性は意外に高いことが分かる。
複数のODF実装の間の互換性
| Implementation | Raw Score | Raw Score Percentage | Weighted Percent |
|---|---|---|---|
| OpenOffice | 151 | 100% | 100% |
| StarOffice | 149 | 99% | 97% |
| Sun Plug-in for Word | 142 | 94% | 96 |
| Clever Age/MS Plug-in for Word | 139 | 92% | 94% |
| Wordperfect | 122 | 81% | 86% |
| Koffice | 121 | 80% | 79% |
| Google Docs | 117 | 77% | 76% |
| TextEdit | 55 | 36% | 47% |
| Abiword | 48 | 32% | 55% |
複数のOOXML実装の間の互換性
| Implementation | Raw Score | Raw Score Percentage | Weighted Percent |
|---|---|---|---|
| Office 2007 | 148 | 100% | 100% |
| Office 2003 | 148 | 100% | 100% |
| Office 2008 (Mac) | 147 | 99% | 99% |
| OpenOffice | 141 | 95% | 96% |
| Pages | 142 | 96% | 95% |
| Wordperfect | 114 | 77% | 84% |
| ThinkFree Office | 101 | 68% | 83% |
| TextEdit | 52 | 35% | 43% |
投稿者: 村田 真 日時: 2008.08.06 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLのアピールは終了
ISOとIECから発表があり、OOXMLについての四カ国のアピールに
は却下された。正確に言うと、ISOのTMBとIECのSMBの投票の
結果、アピールの処理をさらに進めるという合意は得られなかった。
この結果を受けて、9月末のSC34韓国会議でWG4(OOXML対応)の
新設が議決され、私がその暫定議長になることが決まるものと
予想される（以前の記事を参照）。
今後は、OOXMLに山ほどdefect reportを出し、それを直していく
という作業になる。40ページ程度のXMLで200を越える誤りが見つ
かっていることを考えると、7000ページのOOXMLには千以上の
誤りはあって当然だろう。日本からも、BRMの積み残しが10程度
あるので、できるだけ早期に提出したいところである。
投稿者: 村田 真 日時: 2008.08.17 | パーマリンク | コメント (0) | トラックバック (0)
OASISのODFとISO（及びJIS)のODFとの乖離
OASISのODFとISO/IECのODFはすでに別物だし、今後もさらに乖離していく可能性がある。JIS規格として用意しているODFは、ISO/IECのODFに基くので、OASISのODFとは別物である。
ODF 1.1 (OASIS) .vs. ODF 1.0 (ISO/IEC JTC1 SC34)
OASISはODF 1.0を制定し、ISO/IEC JTC1に提出した。そのあとで、ODF 1.1をOASIS standardとして制定した。ODF 1.1はISO/IEC JTC1には提出されていない。具体的には、アクセシビリティの機能は、OASISのODF 1.1にのみ存在し、ISO/IEC 26300には存在しない。細かいことをいうと、OASISのODF 1.0 standardとISO/IEC 26300が完全に同一なわけではない。日本コメントで要求したIRI(non-ASCII文字を含んだURI)は、ISO/IEC 26300には含まれるが、OASIS ODF 1.0には含まれていない。
OASISのみに適用される正誤表
日本がJIS ODF原案作成中に報告した誤りの一部（昨年末までに年報告したもののさらに一部）は、OASIS ODF 1.0の正誤表によって対処される。しかし、ISO/IEC 26300がいつどのように修正されるかはまったく分からない。修正しないという話すらOASIS側から出ている。
OASIS側は、ISO/IECのODFをOASISのODFと一致させることに否定的である。そもそも、OASIS standardとしてのODFにある誤りを修正することすら、きわめて反応が遅い。詳しくは、Jasperのブログと、OASISのコメントメーリングリストアーカイブを参照
投稿者: 村田 真 日時: 2008.08.26 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLのテキストが各国に配布された
ついに、ISO/IEC 29500のテキストがSC34参加国に配布された。正式に出版されて一般に入手可能になるのはまだ先だが、これで関係者には入手可能になる。そして、defect reportを提出することが可能になる。
投稿者: 村田 真 日時: 2008.09.26 | パーマリンク | コメント (0) | トラックバック (0)
SC34済州島会議
9/28から10/1にかけて韓国済州島で開かれた会議により、いくつかの重要な決定がなされた。以下の決定はいずれもすべての参加国が賛成している。その中には、アピールに参加したインド、南アフリカ、ブラジルも含まれている。他の参加国は、カナダ、中国、コートジボワール、デンマーク、フィンランド、ドイツ、イタリア、日本、韓国、ノルウェー、イギリス、アメリカである。
- OOXMLのメンテナンスのためにWG4を設立（Resolution 2)し、私がコンビーナとして就任する(Resolution 3)。最初の会議は、来年の2/2から2/4に開かれる。私は、沖縄で開催したいと考えている。
- WG1コンビーナは、私からAlex Brownに交代する(Resolution 4)
- OOXMLの欠陥報告を各国及びリエゾンから集めるためのWeb Formをもうすぐ運用し始める(Resolution 5)
- ISO/IEC 26300(ODF)のメンテナンスが滞っていることについてOASIS ODF TCにリエゾン文書を送る(Resolution 6)。また、メンテナンスに関する合意に問題があってSC34が責任を果たせないため、 JTC1に対応を要請する(Resolution 7)
- オフィス文書の相互運用性を扱うWG5を設立(Resolution 8)し、韓国のLee教授がそのコンビーナとして就任する（Resolution 9)。
- ODFとOOXMLの相互変換についてのtechnical reportを作るプロジェクトを、これらのISO/IEC規格だけを対象とする（すなわちODF 1.1は除く）と限定した上で、WG5に割り当てる(Resolution 10)。この相互変換TRのproject editorとして、とりあえず中国のMr. Ning LI と韓国HaansoftのNAM, Dong Sunを任命し、ドイツから推薦される候補者をあとで追加する(Resolution 11)。
OOXMLの最終テキストに基づくメンテナンスはすでに始まっている。まず、日本が口火を切って欠陥報告を提出し、イギリスが追随した。今後、各国から山のように欠陥報告が提出されるだろう。それを審議するのが、WG4の当面の仕事となる。インド及び南アフリカの代表とはいろいろ話したが、彼らは盛んに欠陥報告を提出し、WG4の審議に積極的に参加してくるだろう。
Resolution 6とResolution 7のレターはイギリスが中心となって起草したが、Resolution 7のほうのレター作成にはインド、デンマーク、アメリカも立ち会っている。もともと日本の欠陥報告が、ISO/IEC 26300の改正に繋がらない（したがってJIS ODFで困る）ことがきっかけとなっている。
詳細は、SC34の決議を参照されたい。いつもながら、Alex Brownのblogが有益な情報を提供している。
投稿者: 村田 真 日時: 2008.10.04 | パーマリンク | コメント (0) | トラックバック (0)
SC34におけるOOXMLの今後
私はSC34/WG4(OOXML)のコンビーナとして、SC34における今後のOOXML
の保守・拡張をもっとも良く知ることになった。最初に始まるのは、BRMで決
まった修正が正しく反映されているかを確認し、欠陥報告によって修正して
いく（つまり正誤表を発行していく）ことである。来年前半ぐらいまではそれが
ほとんどの作業になるだろうが、少しずつ改正・拡張作業も始まると予測している。
たとえば、SC34/WG2からはフォント埋め込みに関する機能拡張の要求が
すでにあった。
OOXMLへの日本から意見を提出するには、すべてSC34専門委員会を経由
することになる。今後、SC34専門委員会に加わろうという企業・大学が増えることを
期待している。
SC34/WG4が欠陥報告を集めるためのWebページは一般には公開されず、
各国とリエゾンにしか公開されない。国内からSC34専門委員会に欠陥報告
を提出するためのWebページも要請があれば検討したい。
投稿者: 村田 真 日時: 2008.10.05 | パーマリンク | コメント (0) | トラックバック (0)
OASISとSC34の間での手打ち
以前の記事で報告したように、OASISのODFとISO/IECのODFにはいろいろと
乖離がある。また、正誤表がなかなか出ないという問題がある。現状について
はAlexの記事が詳しい。
今回、JTC1奈良総会において、OASIS（及びIBM)とSC34の側の話し合いが
JTC1議長同席のもとに行われ、今後は協力体制を取っていくことになった。
この件に関する決議が出る予定である。また、2009年3月のSC34総会に、
OASIS側も参加することになった。
追記: 決議案は、SC34のプレゼンテーションの最後のページにある。
投稿者: 村田 真 日時: 2008.11.12 | パーマリンク | コメント (0) | トラックバック (0)
ISO/IEC 29500 (OOXML)の出版
ついにISO/IEC 29500が出版された。正式なアナウンスを参照。
これから一年近くは、欠陥の修正にSC34/WG4は多くの工数を割くことになるだろう。いつ拡張が始まるのかは私にも分からない。
投稿者: 村田 真 日時: 2008.11.20 | パーマリンク | コメント (0) | トラックバック (0)
ニヤリ
東大の特別講義で、OOXMLとODFの件を話した。この講義の内容については公開
する気はない。しかし、気が滅入るような話が多かったのは確かだ。
もっと明るい話をしよう。山口瞳じゃないが、人の仕事振りを見てニヤリとす
ることが規格の世界でもある。OOXMLの国際投票の件では、イギリスの
Inigo Surguyは素晴らしかった。OOXMLのテキストからXML文書例を抜き出し、構文解
析と検証をするプログラムを書いたことは良く知られている。これは今後の
WG4の活動にも大いに役立つはずだ（OOXMLの最終テキストをこのプログラムに
かけると、いったいいくらエラーが見つかるだろう？）。
DIS時点のOOXMLのスキーマでは、まったく同じsimple typeを複数のモジュー
ルで何度も定義していた。当然、メンテナンス上好ましくない。私は、XSLT2
のプログラムを書いて、同一のsimple typeの重複定義をすべて指摘した（つ
もり） 。イギリスの連中と晩飯を食べながらこの話をしたところ、Inigo も
同じことをしたと言う。ううむ、おぬし出来るな。日本とイギリスのコメント
の結果、完全に重複するsimple typeについては一箇所にまとめられた
(shared-commonSimpleTypes.xsdとshared-commonSimpleTypes.rnc)。OOXMLの
スキーマがマイクロソフトのMSXMLでしか動かないことも、Inigoと私だけが指
摘して修正させた。
イギリスが投票に付したコメントは全体としてまったく大したものである。私
も偉そうな口を利いているが、あれには日本コメントは完全に負けた。悔しい。
日本だけではなく、他国のコメントすべてを質・量ともに圧倒している。大英
帝国の威信いまだ衰えずというところか。
これには後日談がある。OOXMLの最終テキストがSC34内で公開された直後に欠
陥報告を提出したのは日本である。これを知ったイギリスが悔しがること悔し
がること。急いで、いくつか欠陥報告を提出してきた。
いまのところ欠陥報告では日本がリードしているが、これからイギリスは大量
の欠陥報告を提出してくるだろう。遅れをとっては幹事国たる日本の沽券にか
かわる。1月の沖縄会議までに、さらなる欠陥報告を出さざるべからず。
追記: メディア型だけで10ぐらいは簡単に出せる。BRMの積み残しが10程度
あり、 フォントに関連するものも出せる（鈴木先生の論考を参照）。
投稿者: 村田 真 日時: 2008.12.04 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLの出版
OOXMLはすでにISO/IECから出版されているが、それと同一内容のものがEcmaから出版された。
ISO/IECから出版されたのはPDF文書だけだが、Ecmaから出版されたものはdocx形式である。
イギリスは、Inigo Surguyのプログラムを使って、このdocxをチェックするだろう。いくらエラーが出るだろうか？
追記(2009-01-17) 誤りに気がついたので訂正する。Ecmaから一般に公開されている文書
にはPDF形式しかない。docx形式は、WG4のメンバにしか公開されていない。
投稿者: 村田 真 日時: 2008.12.17 | パーマリンク | コメント (0) | トラックバック (0)
ODFのJIS原案見直しと実装解説資料(MS)
今週はODFのJIS原案の見直しにほとんどの時間を費やしている。第二回の規格
調整委員会に掛けるためである。来年にも修正に時間を費やすことになるだろ
う。しかし、ISO/IEC 26300にはまだまだ問題があることを痛感する。
ODF（正確にはOASIS ODF 1.1）規格書への注釈の形で、Office 2007 SP2にお
けるODF実装を解説した資料がマイクロソフトから公開された。Doug Mahughの
ブログ記事が詳細を伝えている。短いが日本語の記事も出ている。
規格書の各節を表示し、Implementation notesをクリックすると、別ウインド
ウにWord/Excel/Power Pointにおける実装についての情報が示される。実装し
ている／実装していないだけの情報しかないことも多いが、もっと情報量があ
ることもある。
私は、規格に携わって長いが、このような文書をはじめて見た。今後は、この
ような文書を実装者が公開することが当然とされていくのかも知れない。
投稿者: 村田 真 日時: 2008.12.19 | パーマリンク | コメント (0) | トラックバック (0)
SC34/WG4&WG5沖縄会議
先週に、最初のSC34/WG4&WG5会議を沖縄で開催した。WG4は、OOXMLの保守を
担当し、WG5は文書の相互運用性（当面はODFとOOXMLの相互変換についての
technical reportなど）を担当する。
この会議で議論された内容については、ここでは述べない。まもなく発行されるであろう
WG4議事録、すでに発行されたWG5議事録を参照してほしい。また、Jesperの記事,
Dougの記事, Alex Brownの一連の記事 1, 2, 3, 4, 5, の記事がよい要約となっている。
ここで述べたいことは二つ。
一つは、SC34/WG4の重要性である。OOXMLがISO/IEC 29500としていったん承認
されてしまえば、あとは放置されるという観測はまったく正しくない。SC34/WG4によって
保守・変更されていくOOXMLに適合するように実装は修正されていくと私は確信
している（ただしタイムラグは当然ながら存在する）。
もう一つは、沖縄の文化（エイサー、カチューシ、音楽、料理など）を参加者にとても
楽しんでもらったことである。前述の記事をみるとそれがよくわかる。WG4もWG5も
決して楽観できる会議ではないが、友好的な雰囲気を醸成することができたと思うし、
私のWG4運営もやりやすくなったと思う。日本についてとても良い印象を持ってもらうこ
ともできた。遠回りのようだが、とても大事なことだと思う。
投稿者: 村田 真 日時: 2009.02.06 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLの欠陥報告は順調に増加中
WG4の一般向けサイトにあるDefect Report Logを見ていただけると分かるが、
OOXMLへの欠陥報告は順調に増加している。沖縄会議に引き続き、プラハ
会議、コペンハーゲン会議、シアトル会議、電話会議によって、欠陥報告に
対処していく。
わずか40頁程度のXML勧告には200以上の正誤表が発行された。OOXMLの規模を
考えれば、100や200はまだ序の口であり、数千ぐらいはとうぜん欠陥報告が提出
されるものと考えるべきだろう。日本からの欠陥報告は、広島大学の鈴木先生の絶大
な貢献によって順調に増え、他国を圧倒している（RELAX NGスキーマについてのものは
作った本人がバグに気づいたというだけの話ではある）。しかし、イギリスが量産体制に
入ってきたので、もっと出していく必要がある。
投稿者: 村田 真 日時: 2009.03.01 | パーマリンク | コメント (0) | トラックバック (0)
ODFは成熟するか？
ODF仕様書の品質には多くの問題があるが、これまで（日本の欠陥報告を除き）
ほとんど指摘されることがなかった。しかし、ODF 1.2のcommittee draft
については、大量のコメントが提出されている。それらは、 アーカイブ（二月分と
三月分）から確認できる。いまのペースから行って、今後もますますコメントは
出されるだろう。私自身はcommittee specificationになった後でコメント
するつもりでいる。
これらのコメントに応えて、ODF 1.2は大幅に改善されるだろうか？
投稿者: 村田 真 日時: 2009.03.15 | パーマリンク | コメント (0) | トラックバック (0)
SC34プラハ会議(OOXML関係分のみ)
3月24日から26日までSC34/WG4(OOXML)会議を開催し、コンビーナを勤めた。また、27日にはSC34総会に出席した。総会の決議を参照。
プラハ会議までに、ISO/IEC 29500(OOXML)について169の欠陥報告が提出された。これらを提出したのは、イギリス、スイス、イスラエル、及び日本である。
これらの欠陥報告に対応して、ISO/IEC 29500を変更する必要がある。必要な変更のいくつかは、technical corrigendaの範囲を超えている可能性があり、むしろamendmentによって扱われる可能性がある。
WG4では、technical corrigendaとamendmentを区別するためのいくつかの評価基準を作成した。これは、WG4の文書としてもSC34の文書としても発行される予定である。
イギリスからの最新の欠陥報告は、小さいが重要な変更を提案している。具体的には、ある属性の許容値をtrue/false/0/1からon/offに変更する。この変更は、Ballot Resolution Meetingでの決定を覆すものなので、詳しく検討することを各国に要請した
ISO/IEC 29500の欠陥のひとつはきわめて重要である。その欠陥は、Ecma最初の版のOOXMLとISO/IEC 29500 OOXMLとを簡単に区別する機構がないことである。何らかの機構を提供しなければならないことは合意されている。この機構は、既存の実装と文書に深刻な影響を及ぼすことは確実なので、慎重に検討する必要がある。WG4での議論の結果、二つの機構とその得失をまとめた文書を作成した。これはWG4の文書としてもSC34の文書としても発行される予定である。
現在ある欠陥報告に対応するため、次回のWG4会議後にDCOR投票とFPDAM投票を開始することを決めた。PDAMではなくFPDAMから開始するのは、欠陥報告に起因する小規模な拡張しか行っていないためである。
今回の会議では、日本からの拡張提案が紹介された。WG4は、各国とリエゾン組織に拡張を提案するよう呼びかけている。
Ecmaには、マイクロソフトオフィスの次のバージョンに必要な拡張のすべてを開示する計画がある。開示は、WG4のシアトル会議で行われる予定である。
適合性試験についての情報交換を行った。Fraunhofer Fokusとマイクロソフトは、OOXMLの実装と文書をテストする体制を作ることを計画している。WG4においても適合性試験用テストデータと適合性試験方法に取り組むことは可能であるが、何の決定もなされていない。
投稿者: 村田 真 日時: 2009.04.02 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLの欠陥への対処
OOXMLについて各国およびEcmaから欠陥報告がいくつも出されている。WG4は、
それらに対処している。対処状況は、グラフを見れば一目瞭然である。
- 左端のグラフの読み方
- 6/10の時点で、262の欠陥報告が出されている。そのうち、106については
WG4としての結論を出している(closed)。31は、二週間以内にWG4の内部か
ら異論が出なければcloseされる。54については、WG4でさらに考慮する必要
があるとproject editorが判定したものである。71については、project editorがまだ
なんの判断も示していないものである。 - 中央のグラフの読み方
- 提出後150日以上たってもWG4としての結論が出ていない欠陥報告は存在し
ない。提出後120日以上150日未満であって、WG4としての結論が出ていな
いものは41件。90日以上120日未満であって、WG4の結論が出ていな
いものは7件、60日以上90日未満であって、WG4の結論が出ていな
いものは5件。以下は省略する。 - 右端のグラフの読み方
- 欠陥報告のうち技術的なものが121件、編集上のものが99件、詳細説明を
求めているのが43件である。
WG4がどのような手続きで欠陥報告に対処しているのかは、IS 29500 Maintenance process and statistics
を参照されたい。6/10時点におけるすべての欠陥報告は、sc34-wg4-2009-0053.pdfにある。
上のグラフから分かるように、欠陥報告を出せば数か月で何らかの結論がある。
OOXMLの実装で困っている人は、リバースエンジニアに頼ったりせず、素直に
国内SC34専門委員会を経由してコメントを提出してほしい。このブログのコメント
として書いてくれてもよい。
追記: 6/11の電話会議の結果を受けて、6/13のデータを出した。常に最新版は、
http://www.itscj.ipsj.or.jp/sc34/wg4/statistics/DefectReportsOn29500.html
にある。
投稿者: 村田 真 日時: 2009.06.12 | パーマリンク | コメント (0) | トラックバック (0)
SC34/WG4コペンハーゲン会議
コペンハーゲン会議(6/22-24)を終え、正誤表と補遺の作成が順調に進んでいる。
正誤表はSC34の投票一回で出版されるが、補遺はさらにJTC1での投票が必要
となる。
今回の補遺はごく小さい拡張である。この程度の規模の拡張ならふつうは正誤表
で済ませるのだが、OOXMLなので慎重に補遺とすることになった。なお、SGMLを
XML互換にする（たとえば<foo/>のような空要素タグを許す）というWebSGML
は、正誤表によって制定されている。
名前空間の変更
今回の補遺でもっとも大きいのは、名前空間の変更である。以下、背景を説明する。
Ecma OOXML 1st editionと、ISO/IEC 29500:2008とでは、いろいろな違いがあるの
にも関わらず、名前空間は同じである。したがって、文書の先頭を見ただけで、
Ecma OOXML 1st editionなのかISO/IEC 29500:2008とを区別する方法はない。実際、
多くのOOXML文書において、それがEcma OOXML 1st editionに従うのか
ISO/IEC 29500:2008に従うのかは簡単には決定できない。
区別できないということは、良い点も悪い点もある。良い点の一つは、ISO/IEC 29500:2008に従う
多くのOOXML文書が、Ecma OOXML 1st editionに従う実装でも動くということである。
悪い点の一つは、動いてしまったときひっそりとデータが化けるということである。とくに、
ISO/IEC 29500:2008に従うスプレッドシートがISO 8601に従った日付を含んでいると、
その日付が誤って解釈される。
名前空間を変更するかしないかで長い議論があった。簡単に言うと、データが化けるか、
クラッシュするかの選択である。名前空間を変えないとデータが化けるだろうし、
変えると既存実装はクラッシュするだろう。結論から言うと、適合性クラスstrictでは
変え、transitionalでは変えないということになった。この決定の結果、strictと
transitionalの関係は、単なるサブセットではなくなる。この方針にしたがって、
いま補遺を作成中である。
ISO 8601の日付
transitionalでは依然としてデータが化ける可能性が残っている。文書を作成した
ソフトウェアがなんであるかを利用するなどして判定すれば十分であるという意見
もある（実装もある）。既存の実装がすぐになくなる訳ではないのだから、それでは
不十分だという意見もある。後者は、ISO 8601に従った日付がとくに化けやすい
ので、transitionalから削除することを主張している。なお、ISO 8601に従った日付
を用いるは当面は少ないと予想されるが確実ではない。
transitionalから、ISO 8601に従った日付を消すかどうかについては、いまだに
決着していない。次回の電話会議で決着させるつもりで、さまざまの折衝が行われ
ているところである。国内からの意見があれば、この記事へのコメントとして提出
されたし。
投稿者: 村田 真 日時: 2009.07.05 | パーマリンク | コメント (0) | トラックバック (0)
ISO/IEC 29500(OOXML)の正誤票と補遺（第一回）の投票開始
7/30の電話会議で、正誤表(Part 1からPart 4のすべて）と補遺（Part 1とPart 4のみ）を、
SC34の投票にかけることが決まった。最短だと、正誤表はSC34での投票一回で発行
される。補遺は、SC34での投票一回のあとJTC1での一回の投票を経て発行されるのが
最短となる。
今回の変更で最大のものは補遺にある。適合性クラスstrictの場合に限って名前空間を
変え、Ecma OOXML (1st edition)と容易に区別がつくようにしたという変更だ。適合性
クラスtransitionalの場合は変わっていない。
現時点でのページ数を示す。
Part 1の正誤票 183ページ
Part 2の正誤票6ページ
Part 3の正誤票6ページ
Part 3の正誤票35ページ
Part 1の補遺189ページ
Part 4の補遺155ページ
正誤票や補遺は今回が最後ではない。日本から提出した欠陥報告にも積み残しは
いろいろある。とくに、フォントについての欠陥などは、日本に直接影響する。
来年のおそくとも前半には、また正誤票や補遺をSC34での投票にかけることに
なるだろう。
投稿者: 村田 真 日時: 2009.08.01 | パーマリンク | コメント (0) | トラックバック (0)
OOXMLの欠陥報告のRSSフィード
SC34/WG4に提出された欠陥報告を試験的にAssemblaというシステムで管理している。
その副産物として、RSSフィードが自動的に生成される。以下に四つのフィードを示す。
2009年4月1日以前に提出されているが結論が出ていないもの
投稿者: 村田 真 日時: 2009.08.27 | パーマリンク | コメント (0) | トラックバック (0)
ODF 1.0 (ISO/IEC 26300)のメンテナンスについてのSC34ミーティング
2009 9/15から16にかけて、SC34 Ad-hoc Group 3(ISO/IEC 26300 Maintenance)
のミーティングが開かれる（議題）。
現状
ODFのメンテナンスについては、日本から提出した欠陥報告（一回目と二回目）が
当面の試金石になっている。
一回目の欠陥報告については、OASISはerrataをOASISの文書として発行した（議長
のメッセージを参照）。これをSC34でDraft Technical Corrigendaとして投票にかける
ことが当面の課題である。その次に投票、コメント審議となる。
二回目の欠陥報告については、OASISはまだ検討中である。検討状況については、
OASISのページを参照。
最初の欠陥報告のためのerrataには、一部の修正に軽微な問題（フォントの修正
漏れなど）がある。普通なら投票のときに直せば済む話であるが、OASISですでに
errataとして発行されているので、どうすれば良いのかよく分からない。
二回目の欠陥報告には、一回目より複雑な内容が含まれている。そのうちのいくつか
に対する現在の検討内容はまったく不十分だと私は思う。一例として
Measure Propertiesに関する欠陥報告についての検討内容をあげておく。
日本のポジション
日本のSC34での議論の結果、Draft Technical Corrigenda投票でのコメントに
はきちんと対応するよう主張することに決まった。コメントに答えて、Draft Technical
Corrigendaを直すとともに、OASIS側ではerrataをさらに発行せよと主張する。
今回の会議には、JIS ODFのドラフト（もちろん日本語）、今までに規格調整委員会から
受けたコメントの一覧を持ち込むつもりである。正直言うと、内容を理解せずに
翻訳しているのではないか、原文はひどいが翻訳はもっとひどいという手厳しい指摘
を受けてきている。原規格の品質に問題がある限り、翻訳する側としてはどうしようも
ない。AHG3会議では、ISO/IEC 26300のきちんとしたメンテナンスが必要だと指摘
する。
投稿者: 村田 真 日時: 2009.09.05 | パーマリンク | コメント (0) | トラックバック (0)
SC34シアトル会議報告
重要な決定についてだけ、ごく簡単に述べる。総会決議と総会報告
を参照されたい。さらに詳しい資料の一部は、SC34の文書として公開されて
いる。
JIS ODF原案を作成しながらODF本体へのフィードバックを行ってきた。
今回の会議では、日本に感謝する決議が出た(Resolution 4)。
ODFのメンテナンスを扱うためのWGとしてWG6が発足し、イギリスの
Francis Caveがその議長になった(Resolution 1と2)。
ODF 1.1はこれまでOASISだけの規格であり、JTC1には対応するものが
なかった。ODF 1.1の規格化に必要な資料を、OASISはSC34に提供する
(Resolution 3)。
投稿者: 村田 真 日時: 2009.09.22 | パーマリンク | コメント (0) | トラックバック (0)
Microsoft Office 2010におけるOOXMLの拡張
Microsoft Office 2010で、ISO/IEC 29500をどのように拡張したかが公表された。
- [MS-DOCX]: Word Extensions to the Office Open XML File Format
- [MS-XLSX]: Excel Extensions to the Office Open XML File Format
- [MS-PPTX]: PowerPoint Extensions to the Office Open XML File Format
- [MS-ODRAWXML]: Office Drawing Extensions to Office Open XML
ISO/IEC 29500は、Part 3(Markup Compatibility and Extensions)の機能によって、拡張が許されて
いる。拡張しても適合するし、古い実装を壊すこともない（ただし古い実装がPart 3をきちんと
処理していればの話）。したがって、これらの拡張はISO/IEC 29500に違反しているわけで
はない。
これらの仕様書からXSDスキーマを抜き出し、要素数をカウントしてみた。全部で363要素
ある。これを、ISO/IEC 29500にあるレベルでまじめに記述すると、1000ページぐらいに
なるのではないかと思う。
さて、これらの拡張をSC34/WG4が規格化し（もちろん各国のコメントによって変更
した上で）、ISO/IEC 29500の一部とすべきだろうか？それとも、マイクロソフトの
独自拡張のままにとどめておくべきだろうか？
独自拡張であってもISO/IEC 29500には適合することは前述した。標準化してもOffice 2010
ではなく、その次の版での対処になるだろう。それに、Office 2010は市場から消えないから、
この独自拡張も消えはしないだろう(Ecma 1st edition OOXMLが消えないのと同じ）。
独自拡張は、今後の版のMS Officeでもおそらく導入される。独自拡張をSC34で標準化
しない場合は、ISO/IEC 29500だけを見ても実際として使い物にならず、マイクロソフト独自仕様
に頼らないと実装できないということになるだろう。標準化する場合には、マイクロソフトの
計画によってISO/IEC 29500の拡張は左右されるということに結局なる。
SC34の幹事国にして、WG4のコンビーナ（私）を出している日本の責任は重い。この
件についてはSC34専門委員会だけで決めるのではなく、技術委員会の意見も聞いた
うえで日本としての方針を打ち出すことになるだろう。
1) 全体
363要素
2) Excelの拡張
125要素
EEDrawingmlSlicer.xsd:2
EEExcelMain.xsd:3
EESpreadSheetMain.xsd:120
EEac.xsd:0
3) Wordの拡張
57要素
WE.xsd:57
4) PowerPointの拡張
40要素
PEAudioVideo.xsd:6
PEMain.xsd:34
5)Office Drawingの拡張
141要素
ODEArtDiagram.xsd:2
ODEDrawingChart.xsd:12
ODEDrawingDiagram.xsd:18
ODEDrawingMain.xsd:52
ODEInkMain.xsd:4
ODEPicture14.xsd:2
ODEWordm.xsd:6
ODEWordprocessingCanvas.xsd:10
ODEWordprocessingDrawing.xsd:6
ODEWordprocessingGroup.xsd:11
ODEWordwordprocessingShape.xsd:11
ODEXlSpreadsheetDrawing.xsd:7
投稿者: 村田 真 日時: 2009.09.26 | パーマリンク | コメント (0) | トラックバック (0)
