Hiroaki Sakuma
hiroa****@sakum*****
2005年 3月 27日 (日) 21:03:46 JST
佐久間です． > 「XML→PDF」という話題ですが、ここでいうXMLはどのようなXML文書でしょう > か？『「XML→PDF変換エンジン」が求める独自書式のXML』ということですと、現 > 在使っているPDFJを代替品に入れ替えるという以上の意味は見出せず、汎用的と > はいえないと思います。 独自書式のXMLというのが，まずXMLの概念としておかしいと思うのですが，XMLとい うのはそれ自体が規格であり，XMLで書く，というのはHTMLで書く，と同じレイヤー の話です． XML自体は意味を持たず，単なるデータに過ぎないので，これをどう使うか，という のは外にあるXMLエンジンが考えることです． > また、FSWiki独自で、Wiki文書用XML書式を開発しようという話題でしたら、そ > れはもう少し慎重に考えたほうがいいと思います。（独自すぎるなら結局意味を > なさない＝Wikiテキストで十分なような） 例えば，XML + XSLT -> XHTMLという生成は，XMLというデータを，XSLTというスキー マにより，XHTMLを生成する仕組みですが，同様にXMLというデータから，PDFを生成 するスキーマを書くだけなので，将来的な拡張はスキーマのメンテで済みます． XMLというのは，まさにこういう用途のために提案されている規格であり，速度面で 難がありますが，データの汎用性という意味では現在選択できる最も現実的な解だと 思います． Wikiテキストのままであるデメリットは汎用性を考えていない点で，Wiki文法から他 の形式へのコンバートは常に専用のエンジンが必要で，Wikiのデータを活用する限り， メンテし続ける必要があります． # スキーマを使って他の形式を出力するための機構(プロセッサ)はたくさん開発され # ていますし，今後もXMLの普及とともにメンテされていくと思います # メジャーなところでは，Operaなどのブラウザがスキーマを直接処理できるように # なれば，プロセッサのことすら考えずに済むようになります > これがXHTML（1.1あるいは1.0 strict）ということでしたら、大いに賛成です。 > XHTMLは十分XMLですからね。ただし、ルーズなマークアップではいけないので、 > 妥当性を確保できる仕組みは必要でしょう。 > そこでの最大のポイントはプラグインにあるかと思います。プラグインが作る > HTML（の断片）をそのまま受け入れる現在の仕様は、セキュリティ面でも脆弱性 > を産む温床になりえるなど、改変する意義は大きいと思います。 XML -> XHTMLは可能ですが，XHTML自体は汎用性が無いので，XMLと同等に扱うには障 害が多いです． もちろん，XHTML自体がXMLですから，"FSWikiのXMLデータ=XHTML"という形を取り， XHTML -> PDFといった処理も可能でしょうが，XHTMLの規格が変わった場合，追従し ていく必要が残ります． ===================== Sakuma,Hiroaki hiroa****@sakum*****
Fork