agenda 2003-02（下旬）～ S curse ～

RDF/XML構文を使ったサイトマップを書き直し、とりあえず構造は決定しました。

• sitemap.xml

rss:itemsという語彙を何とかしたいところです。連結した展開名http://purl.org/rss/1.0/itemsを参照すると404というのはどういうことなのでしょうか。

今回気づいたのは、例えばPersonnelというサイト（リソース）をhttp://purl.org/jintrick/Personal/というURIで表してしまってはまずいということです。これはPersonnelというサイトのホームページに過ぎませんから。

というわけでまだPersonnelは匿名リソースなので、rdf:ID属性を付けて参照できる形にしたいところです。全ての匿名リソースにこれを行うなら命名規則をどうするかも考えなければなりません。

サイトマップが完成したら、RDFトリプルをどう扱うかを考える予定です。主語を割り出し、それについて何が述べられているのか、何を述べるか、そういった感覚で操作したいところです。何が述べられているのかが良く分からないときにはRDFスキーマを参照させるのですが、rss:itemsのようにそれが存在しないと困ります。

問題は、どんな変則的な構文にも対応できるようにするにはRDF/XML Syntax Specification (Revised) (英語)を舐めるように読みまわさなければならないことです。そこまでする必要があるのかどうかは兎も角。

ちなみに、私がやっているのは単なる修養であって、セマンティックウェブとは直接関係無いので注意が必要かもしれません。

今朝（昨日の朝）、dive into markの記事How to block spambots, ban spybots, and tell unwanted robots to go to hellにて、Hatenaアンテナが「rude bot」扱いにされアクセス制限をかけられていたことに気づいたので、はてなの代わりに? Mark Pilgrimさんに弁明してみました。

先ほど返事が届きまして、Hatenaアンテナを許可してくれるとのことです。

ここだけの話、どうしてもdive into markが読みたいというわけでもないのですが、あそこはとにかく影響力があるので、ロボットのリストを参考にされてしまった場合、英語圏の他のサイトの更新情報も取れなくなってしまう危険があったのです。

ある一つの文法に基づくXML文書群から、そのスキーマを定義するXML Schema文書を推論するというツール「Microsoft XSD Inference 1.0 」。オンラインで利用できるので使ってみたのですが……

一つのXML文書からinferとやらをしただけでは精度の低いXML Schema文書しか生成されないので、続けて他のXML文書でrefineとやらをする必要があるのですが、結局最終的に自分の目で確かめないことには精度が怪しいのです。しかも出来あがったXML Schema文書は、型定義等がローカルな位置に散在しており、それらを一つ一つ微調整したりするのは苦痛でした。

やはりというか、フラットな位置に並んだ見出しの登場順序は検証できませんが、きちんと構造が明示された定型的なXML文書、例えばRSS文書用のXML Schema文書を作るのなら、ゼロから書くより効率的かもしれません。

XSLTクイズをやってみました。

• XSLT Quiz

XML:
<snipsnap>
<snip>
<name>'2003-02-22</name>
...
</snip>
</snipsnap>

XSLT:
...
<template match="snip[number(substring(name,1,4))!=NaN]">...

http://dubinko.info/blog/2003_02_23_archive.html より

「子要素nameの（集合の）string-valueの1文字目から4文字目までを抜き出したものを引数にしたnumber関数の戻り値が、非数値（NaN）にならないsnip要素」にマッチさせるテンプレートのつもりなのでしょう。この誤りを指摘せよというクイズです。

まずこの比較式の右辺の「NaN」は、非数値（NaN）としてでなく、ノード集合として評価されてしまう筈です。

問題は、その「非数値」というデータ型を、XPathでどうやって表現するのかという点だと思います。私は明示的な方法を知りませんでしたので仕様書を見るという「カンニング」をしたところ、非数値（NaN）を返す関数が特別に用意されているわけではないようです。また、非数値（NaN）は、XPathではNumberのデータ型の特殊な形態であるということも分かりました。

結果的に非数値（NaN）を返す関数なら複数あります。最もシンプルそうなものはstring型のデータを引数にしたnumber関数でしょうか。

<template match="snip[number(substring(name,1,4)) != number('a')]"          />

と、これで終了の予定だったのですが、MSXML君は両者を異なるオブジェクトと解釈するようです。仕様書を見てもNaN同士の比較についての記述を発見できませんでした。でもNaNは数値の一種なのですから……不具合?

<template match="snip[string(number(substring(name,1,4))) != string(number('a'))]"          />

'NaN'という文字列同士の比較にすることで解決。XSLTを無理矢理に妥当性検証プロセッサとして使う時に役立つかもしれません。他のプロセッサではどうでしょう。

でも本当に非数値を明示的に表すXPath表現って無いのでしょうか。isNaN()みたいなブール値を返すものも無いようですし。何やら気持ちの悪いものがあります。

2.の答えが待ち遠しい。もしかして、ああいう形式の「質問」だったりして……1.はまさかとは思いますが。

二つの色をブレンドした色を割り出してくれます。ウェブページの配色に同系統以外を使いたいという方にお勧めです。Eric Mayerさん作。

• Color Blender (英語)

お好みの色（コンセプトカラー）と、もう一色は明度、彩度の低い色か、色合いがそれほど違わない色を指定すると良いかもしれません。良く分からない場合は白（#FFFFFF）か黒（#000000）を指定すれば安全?です。

尚、前景色（文字の色）は、背景色の明度が高い場合は黒、低い場合は白にするのが無難です。それ以外にする場合、色弱の閲覧者（私含む）が読みにくくなるか全く読めなくなる可能性にご注意ください。モニターに映った色を信じず、明度の数値を比較するようにして頂きたいのです。

実際は「ブラウザで確認」する人が多いので、本気で読めないスタイルがウェブ上に1割くらい存在しています。だからこそユーザースタイルシートに凝るわけですけれども。ともかくHTML文書と同様、コントラストは「ブラウザで確認」すべきではないと思います。特に、部屋を真っ暗にしてCSSを作成すると大抵「誰かが読めない」スタイルが出来あがります。

単一のXML Schema文書で複数のXML文書を検証するための実用化に向けて動いてみました。

一番の問題点と言えば、ルート要素にxsi:schemaLocation属性（名前空間を持っている場合）あるいはxsi:noNamespaceSchemaLocation属性（名前空間を持っていない場合）を記述して、スキーマ文書へのリンクを作成しなければならない点です。より正確には、それらの属性を記述することによってパーサがスキーマ文書を必ず読み込んでしまうのが問題です。

パーサが賢ければ問題にはならない筈ですが、残念ながらMSXML君は自動でキャッシュを利用してくれることは無いようです。それどころか、standalone="yes"と宣言しても、あるいは、validateOnParse = false; と設定しても、ご丁寧に長大なスキーマ文書を読み込んでしまうようです。

どうしようもないので、先に挙げたxsi:schemaLocation属性やxsi:noNamespaceSchemaLocation属性を記述せずに、任意のスキーマ文書でそのXML文書を検証する方法を探ってみました。

var cache = new ActiveXObject("Msxml2.XMLSchemaCache.4.0");

cache.add('', 'C:\\schema\\hub-jtr.xsd');

var doc = new ActiveXObject('MSXML2.DOMDocument.4.0');
doc.async = false;
doc.load('C:\\Documents\\index.xml');
doc.schemas = cache;

var err = doc.validate();
if(err.errorCode !== 0)
alert(err.line + ' : ' + err.reason);

スタイルシートで変換したXHTML文書は、整形性は大抵保っているものの、バリデータにかけると悲惨な状態であることがしばしばあります。また大量の文書を処理する際、妥当でない文書を考慮に入れると大量のエラー検証用のコードを紛れ込ませなければならず非効率です。色々と必要性が出てきましたので、自家製XML用の妥当性を検証するためのXML Schema文書を書き始めました。

• hub-jtr.xsd

<body>
	<j:dl>
		<dt>foo</dt>
		<dd>bar</dd>
	</j:dl>
</body>

<xsd:group name="Section1.class">
	<xsd:sequence>
		<xsd:element ref="h1" minOccurs="1" maxOccurs="1"              />
		<xsd:group ref="Text.class" minOccurs="0" maxOccurs="unbounded"              />
		<xsd:group ref="Section2.class" minOccurs="0" maxOccurs="unbounded"              />
	</xsd:sequence>
</xsd:group>

<xsd:group name="Section2.class">
	<xsd:sequence>
		<xsd:element ref="h2" minOccurs="1" maxOccurs="1"             />
		<xsd:group ref="Text.class" minOccurs="0" maxOccurs="unbounded"              />
		<xsd:group ref="Section3.class" minOccurs="0" maxOccurs="unbounded"              />
	</xsd:sequence>
</xsd:group>

<!-- 以下同様にSection6.classまで定義 -->

<!-- a character encoding, as per [RFC2045] -->
<xsd:simpleType name="Charset">
  <xsd:restriction base="xsd:string"             />
</xsd:simpleType>