SVG DOM は当面無視することにしました

JavaScript オブジェクトで転送してきた地図情報を SVG 記述に展開するに当たり、

SVGXML マークアップ言語と考えては面倒だ。JavaScript 上の 2D グラフィックスライブラリと考えるんだ。

という発想がありました。そこで、SVG 1.1 勧告の Appendix B (http://www.w3.org/TR/SVG11/svgdom.html)、Appendix C (http://www.w3.org/TR/SVG11/idl.html)、Appendix E (http://www.w3.org/TR/SVG11/ecmascript-binding.html) あたりを眺めてみました。
結論は、

SVG DOM に定義された専用のメソッド・プロパティを使っても XML の DOM 操作を排除することができない。SVGXML マークアップ言語だと考えて SVG DOM を忘れた方が世界観が単純になる。

となりました。よくわかっていないのかもしれないのですが、SVG DOM のクラスのインスタンスを作る方法(new とか)は SVG DOM には用意されていないようで、結局ここで document.createElementNS を使わざるを得ないようです。また、かなり多くのプロパティが readonly で、各種操作を SVG DOM 経由ですることを狙ってみていると、ちょっと失望してしまいます*1SVG DOM は、グラフィックライブラリとしては閉じていなさすぎると感じました。SVG DOM に定義された、やたらと多くてやたらと名前の長いクラス名を覚えるのも苦痛ですし、ここは SVG DOM のことは完全に忘れて、SVGマークアップXML DOM を使って組み上げていくことを考えた方が良いと思いました。というわけで、

SVG DOM のオキテ: 忘れろ

ということでいきたいと思います。

蛇足

ここにおいても、XML とクラスベースオブジェクト指向とは調和していません。XML を使うとき、ほとんどの場合にはクラス指向は余計だと、どうしても思うのです*2。同じ理由から、XML Schema はどうしても(以下省略)。

明日はもう少し前向きな記事にしたいと思います

今日の記事も建設的な記事であるつもりなのですが、明るい記事ではありませんでした。次回はもう少し明るい気分になれる記事を用意したいと思います。

*1:かといって immutable であることを狙っているわけでもなさそうな感じで、このたくさんの readonly の意図を理解することができませんでした。

*2:もう常識でしょうか?