Naoki Takezoe
takez****@gmail*****
2005年 3月 28日 (月) 10:31:06 JST
竹添です。 On Sun, 27 Mar 2005 21:03:46 +0900, Hiroaki Sakuma <hiroa****@sakum*****> wrote: > 佐久間です． > > > > 「XML→PDF」という話題ですが、ここでいうXMLはどのようなXML文書でしょう > > か？『「XML→PDF変換エンジン」が求める独自書式のXML』ということですと、現 > > 在使っているPDFJを代替品に入れ替えるという以上の意味は見出せず、汎用的と > > はいえないと思います。 > > 独自書式のXMLというのが，まずXMLの概念としておかしいと思うのですが，XMLとい > うのはそれ自体が規格であり，XMLで書く，というのはHTMLで書く，と同じレイヤー > の話です． いしださんが仰っているのは独自スキーマということですよね。 > 例えば，XML + XSLT -> XHTMLという生成は，XMLというデータを，XSLTというスキー > マにより，XHTMLを生成する仕組みですが，同様にXMLというデータから，PDFを生成 > するスキーマを書くだけなので，将来的な拡張はスキーマのメンテで済みます． > XMLというのは，まさにこういう用途のために提案されている規格であり，速度面で > 難がありますが，データの汎用性という意味では現在選択できる最も現実的な解だと > 思います． > > Wikiテキストのままであるデメリットは汎用性を考えていない点で，Wiki文法から他 > の形式へのコンバートは常に専用のエンジンが必要で，Wikiのデータを活用する限り， > メンテし続ける必要があります． Wikiテキストの場合も、FSWikiではパーサの抽象クラスを提供していますから、 FSWikiの中に限って考えるのであれば、XSLTなりDOMを使って整形するのと それほど差はないと思います（むしろXMLから変換するほうが面倒かも）。 ただ、外部ツール（特に別の言語で実装する場合）を考えた場合は、例え独自スキ ーマであってもXMLのほうが有利なのは確かでしょう。 > > これがXHTML（1.1あるいは1.0 strict）ということでしたら、大いに賛成です。 > > XHTMLは十分XMLですからね。ただし、ルーズなマークアップではいけないので、 > > 妥当性を確保できる仕組みは必要でしょう。 > > そこでの最大のポイントはプラグインにあるかと思います。プラグインが作る > > HTML（の断片）をそのまま受け入れる現在の仕様は、セキュリティ面でも脆弱性 > > を産む温床になりえるなど、改変する意義は大きいと思います。 > > XML -> XHTMLは可能ですが，XHTML自体は汎用性が無いので，XMLと同等に扱うには障 > 害が多いです． > もちろん，XHTML自体がXMLですから，"FSWikiのXMLデータ=XHTML"という形を取り， > XHTML -> PDFといった処理も可能でしょうが，XHTMLの規格が変わった場合，追従し > ていく必要が残ります． 実際やるとしたらXHTMLのサブセットという感じになるのではないでしょうか。 生HTMLを受け取らないというのはちょっとイメージわからないですね。 Wikiの記法でフォームとかも生成できるようになるということでしょうか。 ただ、HTMLを受け取らないようにしても、Wiki形式のプラグインやその他のプラグ インでもいくらでもセキュリティホールになり得るわけで、あまり意味がないような気も しますけど…なんか勘違いしてます…？ あと、複数行プラグインについてですが、いしださんのリージョンというは言葉的にも 概念的にもちょっとわかりにくいんじゃないかなぁと思います。 -- Naoki Takezoe <takez****@gmail*****>
Fork