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をどのように拡張したかが公表された。
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)
マイクロソフトのDocument Interop Initiative(DII)イベント in シアトル
シアトルで2009-9-19に、マイクロソフトのDocument Interop Initiative(DII)イベントが
開催された。SC34のメンバ10人程度が参加し、私も参加した。
この場で、別の記事に書いたMicrosoft Office 2010におけるOOXMLの拡張が始めて公開された。
前回の記事では仕様書のみにリンクしたが、DIIイベントでの説明資料のほう
が分かりやすいかもしれない。
DＩＩイベントでは、マイクロソフトの独自拡張の説明、それらをSC34で標準化するかどうか
についての議論のほかに、いくつかの興味深い議論があった。
独自拡張のスキーマとISO/IEC 29500のスキーマをどう繋げるか
私はNVDLが良いと思うが、NVDLを知らない人には抵抗があるようだ。なお、
独自拡張のスキーマを見てみると、これがまたISO/IEC 29500のスキーマを呼び出
している。したがって、NVDLを利用するとスキーマの読み込みに関する限りは、
確かに二度手間になるという問題はたしかにある。私は、大したことではないと
思うが、実際にNVDLによる検証を試してみないと本当のところは分からない。
MCEの実装をどのように推進するか
おそらく、マイクロソフト以外にMCEを正しく実装しているところはないだろう。今後、
MS Office 2010の文書が流布するにつれて、MCEを正しく実装していないものは
すべてクラッシュすることになるかも知れない。どうやればMCEの実装を推進でき
るのか、マイクロソフトはアドバイスを求めていた。
実装ノート
マイクロソフトは、ODF 1.1の各節に対し、それをどのように実装したかというノート
を公開している(DIIのページのReferenceボタンを押してODFを選ぶとMSIEなら
きちんと出る）。このようなノートの形式は標準化すべきだろうか？そして、
ノートを提出することを適合性の条件とすべきだろうか？
拡張部分に関するODFとの共通化
今後の拡張部分についてだけでも、出来るだけODFと共通化すべき
だろうか？簡単に出来るのならだれも反対しないだろうが、いろいろ
無理は出てくる可能性が高い。本体が違う以上、無理に合わせても
仕方がないのだろうか？
テスト
相互運用性を保証するためのテストデータやプロファィルを作るべき
だろうか？
投稿者: 村田 真 日時: 2009.09.27
| パーマリンク
| コメント (0)
| トラックバック (0)
