第4回 plist（プロパティリスト）とFoundation【後編】：Undocumented Mac OS X（2/3 ページ）

[白山貴之，ITmedia]

XMLと見た場合のplist

　/System/Library/DTDs/PropertyList.dtdには、plistのDTD*が用意されてる。このDTDを一見すると分かるように、plistのXMLとしての仕様は極めて単純で、わずか9つのエレメントだけが定義され、アトリビュートに至っては何も定義されていない。

　このため、plistによる表現はXMLと見ると極めて冗長だ。例えば、iTunesのライブラリを管理するiTunes Music Library.xmlでは、アーティストを示すのに次のように表現している。

<key>Artist</key>

<string>ARAI Akino</string>

　通常のXMLなら、これは次のようにArtistエレメントを用意するだろう。

<Artist>ARAI Akino</Artist>

　これは、plistがほかのXMLと違い「構造」だけを定義し、その「意味」はplistを読み書きするアプリケーションが決めるからである。この例で言うならやはただデータの構造を表すだけで、その意味はArtistというキーが示している。一方、はタグ自身が意味を持つという違いがある。

plistがもたらすもの

　前述の違いは、実際にアプリケーションを開発する場面になって表れてくる。

　plistでは、どのエレメントがどのクラスと結びつくかは、1対1で明確に定められており、クラスライブラリとも強く結びついている。このため、読み書きに関しては各フレームワークに用意されているもので十分であり、わざわざパーサーに頼る必要がない。Mac OS Xでのアプリケーション開発、特にCocoaのプログラミングではNSStringやNSArray、NSDictionaryといったFoundationの提供するデータ構造はごく当たり前に使用されているため、それをそのまま書き出し、読み込めばいい。その読み書きに際しても、例で示したとおりそう難しくはない。このため、開発者はどういったキーを用意し、どういった構造でデータを持つかというアプリケーション本来の部分に専念できる。

　一方、通常のXMLでの開発では、まず読み書きのルーチンの開発から始まる。XMLパーサーライブラリは多々存在するが、これらはXMLという「構造」を理解し、またDOMなどで提供されるエレメントの文法チェックはしてくれるかもしれないが、そこからどういったメモリ上のデータ構造を作り出すか、メモリ上のデータ構造からどういうXMLを書き出すかは開発者が手を出さなければならない部分になる。前述の例でいえば、というタグをどう解釈し、メモリ上でどのような構造にするか、どのクラスと関連づけるかは開発者がいちいち考えなければならないのである。plistはフレームワークに強く結びついており、開発にかかる負担が軽くなるということだ。

　なおplistでは、一般のXMLと異なり、意味の部分まで踏み込んだ文法チェックはなされないという点に注意する必要がある。Artistの例で言うなら、次のような状態となっていてもパーサーは何も警告しない。

<key>Artist</key>

<array>

<string>1</string>

<string>2</string>

</array>

　こうした、意味を伴う文法の確認は開発者側の責任*となる。

このページで出てきた専門用語

DTD

Document Type Definition。構成要素、親子関係、指定できる属性などについて定義したもの。

意味を伴う文法の確認は開発者側の責任

これに限らず、Cocoaというフレームワークは何かと「ユルい」部分が多い。そこを非難する人も多いが、むしろユルさを肯定的に受け止め、普段はユルく開発を行い、要所要所できっちり締めるのがCocoa流というべきなのだろう。