①Title：SVG
②用語記述：W3C、SVG
③解説：
インターネット技術の標準化団体W3C (World Wide
WebConsortium)が2003年1月14日に、XMLベースの2次元ベクトル・グラフィックス用言語「SVG(ScalableVectorGraphics)1.1」と、SVGのモバイル機器向けプロファイル「MobileSVGProfile」をW3C勧告
(Recommendation) として公開した（http://www.w3c.org/TR/2001/REC-SVG-20010904/）。
SVGでは、ラスタ・イメージに加え、テキストと直線/曲線などベクトル・オブジェクトを使用して画像を記述する。そのため、SVG形式の画像は縮小または拡大しても画質が低下しにくいという特徴がある。デスクトップ・パソコンの大画面から携帯電話機の小さな液晶ディスプレイまで、1つの画像データで対応できるのだ。
またSVG 1.1と共に公開されたMobile SVG
Profileは、第3世代(3G)携帯電話機向けの「SVGTiny」と、PDAなど向けの「SVGBasic」というプロファイルを定義している。両プロファイルはSVG1.1のサブセットであり、モバイル機器でSVGに対応する際のガイドラインとして参照できる。
柔軟性に欠けるラスタ・イメージ
現在Web環境で画像を表示するには、JPEGまたはGIF形式のラスタ・イメージを使うことが一般的だ。この方法には、表示環境に寄らず常に同じ画像を表示できるという特徴がある。しかしこれは、あらかじめ想定していた大きさ以外の画面では画質の維持が難しいことも意味する。
いくら同じ画像だといっても、単純に画面に合わせて拡大または縮小するだけでは問題が起きるのだ。大きな画面用に拡大すれば、画像は粗くなる。せっかく細かいところまで表示できるはずの大画面なのに、それを生かせない。それに対し、画像を縮小すると細かい部分がつぶれて見えなくなる。これでは情報が失われてしまうので、情報伝達手段としては不適切だ。
つまり、ラスタ・イメージの場合、1つのデータだけで異なる大きさの画面に対応するのは難しい。画像表示手段としては柔軟性に欠けているのだ。
SVGでは拡大/縮小が自由自在に
JPEGやGIFのようなラスタ・イメージと異なりSVGは、直線や曲線、四角形、円/楕円など"線"を使って基本的な図形オブジェクトを描画し、それらを組み合わせて画像全体を構築する。
各オブジェクトは配置する位置と大きさが決まっているだけだ。描画の基準となる縮尺を変化させれば、いくらでも大きさを変えて描き直せる。大画面用に画像を拡大するのなら、表示したいサイズに応じて縮尺を変えればよい。それに合わせて図形オブジェクトを再描画するので、改めて細かいところまで正確に拡大できる。その結果、小さな画面では見えにくかった部分もはっきりと見えるようになる。
小さな画面に表示する場合にも、SVG形式のデータは何かと便利だ。縮小してもラスタ・イメージほど画質が低下しない。画面に合わせて図形を再描画できるので、細かい部分をつぶさないよう処理しやすいからだ。また、あまりに小さな画面を使っていて画像がつぶれてしまう場合には、画像全体を表示するのではなく一部だけを拡大表示して見えるようにする、といった対応も簡単だ。
SVGはベクトル情報で画像を表現するので、自由自在に拡大/縮小できる。そのため表示画面の大きさが異なっていても、画面の種類ごとに別のデータを用意しておく必要はない。データが1つあれば対応できる。
またSVGには、表示に使う画面の種類が1つだけの場合にもメリットがある。たとえば、PDAの小さな画面で地図を見るとしよう。このような状況では、まず全体を把握するために広い範囲を表示する必要がある。この時点では概要を知りたいので、画像がつぶれて細かい部分が多少読みにくくても問題ではない。次に地図の詳細を調べるには、見たい部分を拡大表示する。こうすれば、それまでつぶれていた画像も難なく読み取れる。こうした処理は、画像を容易に拡大/縮小できるSVGならば朝飯前だ。SVGの有用性を発揮できる典型的なパターンと言える。
ネットワーク接続機器の多様化で生きるSVG
従来ネットワークに接続する機器といえばパソコンだった。つまり、コンテンツ提供者はパソコンだけを想定してデータを制作したものだ。パソコンの表示画面は一般的にかなり広く、大きさもそれぞれ似通っているため、画像データをラスタ・イメージ形式にしておいても問題は起らなかった。
しかし最近は、ネットワークが生活や社会活動に欠かせないものになり、外出中であっても頻繁にアクセスするようになってきた。持ち運べる機器の大きさに制約のあるモバイル環境においては、大きな画面を持つパソコンの利用は難しい。ネットワーク接続にPDAや携帯電話機といったコンパクトな機器を使うようになったのも自然なことだ。
その結果、今では携帯電話機に付いている約100ピクセル角という小さな画面から、パソコンの1000ピクセル角以上という大画面まで、さまざまな画面に応じなければならない。もはや1種類のラスタ・イメージ・データでは対応できないのだ。
SVGは、表示機器の種類を選ばず、それぞれの能力やその時々の必要性に応じて画像をダイナミックに変更できる。"1種類のデータで多くの機器に最適な表示を行える"のだ。そしてこの特徴は、情報アクセスに多種多様な機器を利用する環境で生きてくる。
W3CがSVG本体の仕様やモバイル機器向けサブセット規定を明確にしたことで、「各ベンダーは独自サブセットを定義するのではなく、2つあるプロファイルのどちらかに対応することで、さまざまな機器間のコンテンツ相互運用性を保証できるようになる」(W3C)。その結果、画像コンテンツ制作の際に、表示機器の相違を意識しないで済むようになる。
つまりSVGは"画像を記述するための共通基盤"であり、「コンテンツ制作者に対し"コスト削減"、"利用可能範囲拡大"、"表示する画質の均一性"という3つの利点をもたらす」(W3C)。ネットワーク接続機器は今後もますます多様化していくと考えられる。SVGは、ユーザに対しても大きなメリットとなるのだ。
SVGのサポート情報と参考サイト
現在、ネイティブでSVG機能をサポートしているのはmozillaのみです。アドビ社からはAdobeSVGViewerというソフトが無償で提供されています。InternetExplorer5.0,5.5,6.0およびNetscape4.7,6.0,7.0でプラグインとして利用できます。
Adobe SVGゾーン
日本語でのSVG情報源として貴重なサイトです。SVGViewerもダウンロードできます。
http://www.adobe.com/jp/svg/index.html
CSIRO SVG Toolkit
Java2で作成されたSVGの専用ブラウザです。無償で利用できます。
実行するにはJava2 SDKまたはJava2 Runtime Editionが必要です。
http://sis.cmis.csiro.au/svg/
Apache Batik
ApacheXMLプロジェクトの１つです。こちらもSVG専用のブラウザですがラスターイメージへの変換機能もあります。またメニュー以外は国際化されているためメッセージも日本語で表示されるので非常に便利です。
実行するにはJava2
SDK1.3以上またはJava2RuntimeEdition1.3以上が必要です。
http://xmlgraphics.apache.org/batik/
④Reference：
W3Cの2次元ベクトル画像表示言語「SVG 1.1」が勧告に
http://xml.fujitsu.com/jp/comment/2003_3/03_11.html
SVGの作成方法他
http://www.asahi-net.or.jp/~uf4k-nkjm/SVG/
⑤作成者：山本正司
①Title：MathML
②用語記述：HTML、MathML、Mozilla、Firefox、W3C、DTD、XHTML、XML
③解説：
MathMLは、HTMLで文書を電子化したように、数式を電子化するためのマークアップ言語です。MathMLの利用により、インターネット上で、数式を、HTML文書のように、公開したり、それを見たり、また、それを処理したりできるようになります。
MathML利用環境を整える
MathMLを表示できるブラウザとして、フリーソフトのMozilla、そして,その後継のFirefoxがあります。MozillaとFirefoxは、ともにhttp://www.mozilla.org/で配布されています。Mozillaは、公開されたNetscapeCommunicatorのソースコードをもとに開発が始められました。Firefoxは,Mozillaに比べ、ポップアップ広告の非表示、タブブラウザとしての機能などの点で強化されています。
MathMLの書き方
MathMLを含む一般的なHTML文書は以下のように記載します。Mozillaで表示するには、拡張子をxmlとします。
<?xml version="1.0" encoding="Shift_JIS" ?> ...(1)
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN"
"http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd">...(2)
<html xmlns="http://www.w3.org/1999/xhtml"
xml:lang="ja"lang="ja" > ..(3)
<head>
:
: 省略
:
</head>
<body>
<p>数式
<math xmlns="http://www.w3.org/1998/Math/MathML">...(4)
<mrow> ...(5)
<mi>x</mi> ...(6)
<mo>+</mo> ...(7)
<mn>1</mn> ...(8)
<mo>=</mo>
<mn>2</mn>
</mrow>
</math>
を表示します.</p>
:
: 省略
:
</body>
</html>
数式 x + 1 = 2 を表示します。
まず、MathMLを含むHTML文書全体について見ていきます。MathMLを含むHTML文書は、まず上述(1)のようなXML宣言で書き始めます。次に、(2)のように、MathMLを含んだXHTMLのDTDを使うことを宣言します。文書は、(3)のように、通常のHTML文書と同じ書き出しで始めます。ただし、xmlns="http://www.w3.org/1999/xhtml"という名前空間の宣言を必ず書く必要があります。また,日本語環境でShift_JIS文字コードを書いた場合です。
実際に数式を書くところには、(4)のように、mathというHTMLにはないタグを使います。mathには、1つ1つxmlns="http://www.w3.org/1998/Math/MathML">という名前空間の宣言を付ける必要があります。
次に、mathの中身を見ていきます。まず、(5)のmrowですが、これは、数式の構成要素を横にまとめるタグです。このmrowは、mrowの中に入れ子にすることもできます。例えば、以下の例のように,上述のmathの中身を表すことができます。また、mathの中に入れるタグは、必ずしもmrowである必要はありません。後述するmi、mo、mnや「MathMLTips集」で紹介する様々なタグを入れることができます。
<mrow>
<mrow>
<mi>x</mi>
<mo>+</mo>
<mn>1</mn>
</mrow>
<mo>=</mo>
<mn>2</mn>
</mrow>
次に、mrowの中身を見ていきます。mrowの中には、mi( (6))、mo( (7) )、mn( (8))の3つのタグが含まれています。まず、miは、x、yといった記号や、sin、cosといった関数名を示すのに使われます。次に、moは、+、-、=といった演算子を表すのに使われます。演算には、","や()等も含まれます。最後に、mnは、数字を表すのに使われます。
MathML Tips集
記載例については、以下を参照して下さい。
http://toshichan.be.fukui-nct.ac.jp/tsujino/mathml/
④Reference：
MathMLとは何か?
http://toshichan.be.fukui-nct.ac.jp/tsujino/mathml/
⑤作成者：山本正司
①Title：DOMとSAX
②用語記述：XML、W3C、DOM、SAX
③解説：
XMLパーサが持つ役割りの中で、XML文書の検証と並んで重要なのが、ソフトウェアがXML文書へとアクセスするための手段の提供である。たとえば、XML文書の読み取り、あるいは読み取ったものに対して何らかの変更を加えるといったことを可能にする機能だ。
こうした機能はXMLパーサが個々で独自に実装しているよりも、共通の形で実装されているほうがユーザーとしては望ましい。XMLパーサごとに独自に実装されていると、そのパーサとそれを利用してXML文書へアクセスしているプログラムの依存関係は強くなる。つまりXMLパーサを切り替えた場合、そのソフトウェアも多くの変更が必要となってしまうわけだ。それに加えて、XML文書へアクセスするための方法をXMLパーサを切り替えるたびに1から習得しなければならないという問題も無視できない。
W3Cで勧告されている「DOM(Document Object
Model)」という仕様は、こうした問題を解決するためのものだ。DOMはXML文書へアクセスするための標準的な方法を定義したもので、XMLパーサがDOMに対応していれば、開発者はどのパーサを使っても(ほぼ)同じ方法でXML文書へとアクセスするためのコードを記述できる。多くのXMLパーサはこのDOMの仕様に準拠しており、標準として広く普及している。
なおDOMは「DOM Level1」と「DOM
Level2」が現在勧告として公開されている。DOM
Level1は1998年10月に勧告となったもので、それから約2年を経た2000年11月にDOM
Level2が勧告された。Level1から2になったことで多くの機能が追加されており、CSSの構文を扱えるようになるなど大きな機能強化も見られるが、地味ながら注目したいのがネームスペースが正式にサポートされたという部分だ。それまでのXMLパーサはネームスペースのサポートに対して、独自に実装してサポートする、あるいはサポートしないなど足並みはバラバラだった。しかしDOM
Level2の登場によって標準的な方法でサポートすることが可能になったのである。
メモリ消費量が少ないSAX
こうして広く普及しているDOMだが、まったく欠点がないわけではない。中でもよく指摘されるのが、メモリ環境への厳しさだ。DOMはXMLを読み込むと、それを木(ツリー)構造としてメモリ上に展開し、ソフトウェアはこの木構造に対してアクセスするという形になる。つまりDOMを使用する限り、XMLはメモリ上にすべて置かれることになり、特に大きなXMLを扱おうとすると多くのメモリ領域を必要とする。こうしたDOMの不満を解消するために登場したのがSAXである。
SAX(Simple API for
XML)の特徴は、イベント駆動型のパーサであるという点だ。イベントには要素の開始や終了、テキストの出現などがあり、XML文書の解析中にこれらのイベントが発生すると、逐一それがソフトウェアに通知される。ソフトウェア側では、それぞれのイベントに対して行なう処理を記述することになる。こうしてイベントを通知したあとの結果は保持されないため、解析している部分しかメモリを消費しない。そのため、巨大なXML文書でも少ないメモリで処理が行なえるわけだ。
このようにメモリ消費量という点ではSAXのほうが有利になる。逆にDOMは、最初に木構造に変換したあと、自由に木構造の中を行き来してアクセスできる(SAXはXMLの構造が複雑になると、プログラム自体も複雑になってしまう)のがメリット。ちなみに現在利用されているXMLパーサの多くはDOMとSAXの両方に対応しているので、開発するプログラムの特性とDOMとSAXの得手不得手を考えて、このいずれかを選択することになるだろう。
まとめ
XMLへアクセスするための方法がDOMやSAXといった形で標準化され、またそれをXMLパーサが対応したことによるメリットは大きい。ソフトウェアをXMLに対応させる際にこれらのXMLパーサを部品として組み込めば、簡単な方法でXMLから必要な情報の読み取りや更新が可能になり、その方法は別のソフトウェアでも利用できる。これによって、XMLに対応させるために必要となる労力を大きく削減できるのだ。今後多くのソフトウェアがXMLを利用すれば、XMLパーサの重要性がさらに増していくのは間違いない。
なお、技術的な解説については、以下を参照して下さい。
http://www.yscjp.com/nfl/td.html
④Reference：
DOMとは?
http://www.infoteria.com/jp/xmlnote/column/doc/xml_column_dom_010420.html
⑤作成者：山本正司
