村田真のXMLブログ http://www.xmlmaster.org/murata/ 日本人で唯一W3CのXMLワーキンググループに参加しXMLの標準化プロセスに携わったXMLの生みの親、村田真さんのブログです。 ja Copyright 2010 Thu, 17 Dec 2009 23:14:42 +0900 http://www.sixapart.com/movabletype/ http://blogs.law.harvard.edu/tech/rss 第1回ウェブ学会シンポジウム 第1回ウェブ学会シンポジウムが開かれたことを今日になって知った。 最近は、OOXMLやODFに多くの時間を割いており、もはやウェブ技術には自分は あまり関わっていないのかもしれない。ただし、XMLスキーマ言語には依然とし て関わっており、RELAX NGの第二版は私がまとめることになっている。]]> http://www.xmlmaster.org/murata/xmlblog/xb091217.html http://www.xmlmaster.org/murata/xmlblog/xb091217.html Thu, 17 Dec 2009 23:14:42 +0900 OOXMLの適合性クラスStrictとTransitinoalの関係についての文書 BRMで決まった適合性クラスstrictを推進するかどうか。過去の互換性のための 機能を許す適合性クラスtransitionalをどう扱うか（凍結・廃止するか、それとも 今後も拡張するかどうか）については、WG4で活発に議論されており、パリ会議 で何らかの進展があるものと期待されています。こんどのad-hocでも、この件は 議論する予定です。 この件についての事情を整理した文書が、WG4で作成されつつあります。まだ 正式には発行されていませんが、今後内容が大きく変わることはないと 思います。 http://mailman.vse.cz/pipermail/sc34wg4/attachments/20091029/047c0ea4/attachment.obj http://www.xmlmaster.org/murata/xmlblog/xb091107.html http://www.xmlmaster.org/murata/xmlblog/xb091107.html Sat, 07 Nov 2009 10:01:36 +0900 SC34/WG4(OOXML)のメールアーカイブ アーカイブがすべて公開された。今後とも、 WG4のメーリングリストに流されたメールはすべて公開される。]]> http://www.xmlmaster.org/murata/xmlblog/xb091107.html http://www.xmlmaster.org/murata/xmlblog/xb091107.html Sat, 07 Nov 2009 09:52:18 +0900 新政権に期待すること 以前の記事を参照）ので、関心がある。 国に求められて地方が提出している報告は、おそらく1000を超えるだろう。 しかもいろいろな無駄がある。うろ覚えで書くが、お金に関することを総ざらい する報告書をなんども別のところに提出する無駄（地方財形状況調査と地方 交付税算定のための調査など）などがある。地方は、国のお金が欲しいから、 大量の報告でも必死になって出すしかないのだ。 韓国の人に、この件では酷評されたことがある。地方のコンピュータと 国のコンピュータが繋がっていれば、大量の報告など要りはしない。 韓国ではそうなっているという。 政権交代は、しがらみを一気に帳消しにするチャンスである。地方が 国に提出しないといけない報告の量を一挙に1/10以下に減らしてしまえば いいと思う。官公庁には増やすことはできても、減らすこと、統合すること などできはしない。政治家にしかできないのだと思う。 ]]> http://www.xmlmaster.org/murata/xmlblog/xb091031.html http://www.xmlmaster.org/murata/xmlblog/xb091031.html Sat, 31 Oct 2009 17:47:34 +0900 盲亀浮木 コラムを書いた。 ご笑覧あれ。]]> http://www.xmlmaster.org/murata/xmlblog/xb091026.html http://www.xmlmaster.org/murata/xmlblog/xb091026.html Mon, 26 Oct 2009 20:27:21 +0900 SC34専門委員会ad-hoc会議 Microsoft Office 2010におけるOOXMLの拡張について書いた。日本としての意見を決める ための参考に、SC34専門委員会ad-hoc会議を11/16日午後2時に機械振興会館（東京タワー のそば）で開催する。この会議には、誰でも参加できる。 日本として考えられるポジションはいくつかある。
  1. Microsoft Office 2010拡張をOOXMLの一部として標準化しようとnew work item proposalを出す。
  2. New work item proposalは出さず、他国から出てきたら反対する。
  3. Microsoft Office 2010拡張を含むあらゆる拡張を、Part 3では許されているのに もかかわらず、禁止するという適合性クラスを導入する。
1と2は背反するが、3は独立である。つまり、1と3の両方を主張することはまったく 変ではない。 このほかにも、このad-hocで意見を聞きたいことはある。
  1. 日本語組版処理の要件 (W3C Japanese Text Layout) に基づく拡張を日本として提案し、貢献していくかどうか
  2. BRMで決まった適合性クラスstrictを推進するかどうか。過去の互換性のための機能を許す 適合性クラスtransitionalをどう扱うか（凍結・廃止するか、それとも今後も拡張するかどうか）。
    3. 追記: 参加するためには、事前の登録が必要である。登録方法については案内を参照。 ]]> http://www.xmlmaster.org/murata/xmlblog/xb091019.html http://www.xmlmaster.org/murata/xmlblog/xb091019.html Mon, 19 Oct 2009 16:09:33 +0900 マイクロソフトのDocument Interop Initiative(DII)イベント in シアトル 別の記事に書いた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と共通化すべき だろうか？簡単に出来るのならだれも反対しないだろうが、いろいろ 無理は出てくる可能性が高い。本体が違う以上、無理に合わせても 仕方がないのだろうか？ テスト 相互運用性を保証するためのテストデータやプロファィルを作るべき だろうか？ ]]> http://www.xmlmaster.org/murata/xmlblog/xb090927.html http://www.xmlmaster.org/murata/xmlblog/xb090927.html Sun, 27 Sep 2009 15:49:39 +0900 Microsoft Office 2010におけるOOXMLの拡張
  3. [MS-DOCX]: Word Extensions to the Office Open XML File Format
  4. [MS-XLSX]: Excel Extensions to the Office Open XML File Format
  5. [MS-PPTX]: PowerPoint Extensions to the Office Open XML File Format
  6. [MS-ODRAWXML]: Office Drawing Extensions to Office Open XML
    7. 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 ]]>     http://www.xmlmaster.org/murata/xmlblog/xb090926.html http://www.xmlmaster.org/murata/xmlblog/xb090926.html OOXMLとODF Sat, 26 Sep 2009 05:23:03 +0900     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)。 ]]> http://www.xmlmaster.org/murata/xmlblog/xb090922.html http://www.xmlmaster.org/murata/xmlblog/xb090922.html OOXMLとODF Tue, 22 Sep 2009 17:10:19 +0900 ODF 1.0 (ISO/IEC 26300)のメンテナンスについてのSC34ミーティング 議題）。

    現状

    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のきちんとしたメンテナンスが必要だと指摘 する。]]>     http://www.xmlmaster.org/murata/xmlblog/xb090905.html http://www.xmlmaster.org/murata/xmlblog/xb090905.html OOXMLとODF Sat, 05 Sep 2009 18:43:26 +0900     OOXMLの欠陥報告のRSSフィード 日本から提出したもの まだ結論が出ていないもの 2009年4月1日以前に提出されているが結論が出ていないもの すべての欠陥報告]]> http://www.xmlmaster.org/murata/xmlblog/xb090827.html http://www.xmlmaster.org/murata/xmlblog/xb090827.html OOXMLとODF Thu, 27 Aug 2009 21:30:57 +0900 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での投票にかけることに なるだろう。 http://www.xmlmaster.org/murata/xmlblog/xb090801.html http://www.xmlmaster.org/murata/xmlblog/xb090801.html OOXMLとODF Sat, 01 Aug 2009 10:31:06 +0900 SC34/WG4コペンハーゲン会議 名前空間の変更 今回の補遺でもっとも大きいのは、名前空間の変更である。以下、背景を説明する。 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に従った日付を消すかどうかについては、いまだに 決着していない。次回の電話会議で決着させるつもりで、さまざまの折衝が行われ ているところである。国内からの意見があれば、この記事へのコメントとして提出 されたし。 ]]>     http://www.xmlmaster.org/murata/xmlblog/xb090705.html http://www.xmlmaster.org/murata/xmlblog/xb090705.html OOXMLとODF Sun, 05 Jul 2009 12:58:17 +0900     OOXMLの欠陥への対処 グラフを見れば一目瞭然である。
    左端のグラフの読み方
    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 にある。 ]]>     http://www.xmlmaster.org/murata/xmlblog/xb090612.html http://www.xmlmaster.org/murata/xmlblog/xb090612.html OOXMLとODF Fri, 12 Jun 2009 22:38:59 +0900     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においても適合性試験用テストデータと適合性試験方法に取り組むことは可能であるが、何の決定もなされていない。 ]]> http://www.xmlmaster.org/murata/xmlblog/xb090402.html http://www.xmlmaster.org/murata/xmlblog/xb090402.html OOXMLとODF Thu, 02 Apr 2009 23:00:15 +0900