S curse
前置きしておきますと、見栄えを完全にCSSで制御しているのなら、ユーザースタイルシートで何とでもなるため、マージンをどう取ろうと問題にはなりません。ただ「WWWメディア対応のスタイルシート」を目指すなら、左右のマージンは出来る限り小さくしておきたいところです。
まず、私のように少ない文字数で折り返しされていると読みづらいという人もいます。というか、どの程度が読みやすいかは個人差があるのですから、それぞれが適当なウィンドウサイズにすることによって読みやすい折り返し文字数を簡単に調整できた方が良いのです。それができるのがウェブページですから。
次に、その文書の概観を掴みたいときがあります。この時どうするかといえば、自分の環境で実現できる最大のウィンドウ幅を利用して、一度に視界に入ってくる段落の冒頭や見出しを可能な限り多くさせます。この場合、左右マージンは邪魔以外の何物でもありません。これについては闇黒日記の平成13年12月22日の記事が参考になると思います。
私も以前は糞真面目に一字一句読んでいたのですが、最近は飛ばし読み
というものの重要性をひしひしと感じています。時間は変わらないのに読むものが多くなったからでしょうか。あるいは既知の事柄が増えた為かもしれません。知っていることをくどくど説明している文章は読み飛ばしたいのです。
闇黒日記の平成13年12月23日の記事を見ると、「左右マージンが少ないと心理的な圧迫感が増す」という問題もあるようですが、ウェブページデザイン（CSSのデザイン）は、ウェブの特性を最大限活かすべきです。従って、そのような「圧迫感」は、別のデザイン要素でカバーするよう努めるべきでしょう。そこが、腕の見せ所というやつなのではないでしょうか。
因みに私の場合、文章に集中している時には、左右マージンが小さくても圧迫感を感じることはありません。ところが、スタイルシートをスタイルとして眺めてみた時、圧迫感を感じることがあります。文章を読みにきた閲覧者を対象にするのか、スタイルを眺めにきた閲覧者を対象にするのか、あるいは、どちらにも満足してもらいたいのか。その辺りで適切な幅が決まるのかなと思っています。
詩など、通常一字一句読むようなコンテンツや、独特の修辞で「読ませる」タイプの「ネタ」などは例外です。ウェブ日記などもどうでしょう。何か特定の目的をもった閲覧者を想定しないタイプの「日記」は、左右マージンを小さくする必要があるかどうか、疑わしいものがあります。しかし、RSSや一部のアンテナ等で何が書かれているかを確認してから読みに行く、という目的志向の閲覧者（私含む）がいないとは限りませんから、長文が多くなる日記では やはり左右マージンは小さくしておいて良いと思います。
おかし日記（３月10日（土））経由で見つけたXPath 1.0を解説しているXMLマスター基礎講座 （XPath編）には誤りが沢山あります。というお話。
ノードを特定するための規格
まずここからして私の認識とは少し違います。XPath 1.0は：
これらを表現するための規格です。ノード集合を表現する方法の一つに「ロケーションパス」がありますが、このXMLマスター基礎講座 （XPath編） で取り上げられているのは「省略文法のロケーションパス」と「一部の関数」です。
'あ'。これも「あ」という文字列を表すXPathの表現です。
とはいえロケーションパスはXPath 1.0の主要な部分であると言われていますから、揚げ足を取ったに過ぎません。もちろん非常に重要だと思うから書いたわけですが。例えばXSLTのvalue-of要素のselect属性には、XPathで文字列を表現したものを記述します。そうでないものは勝手に文字列に変換されているに過ぎません。
基本的には「.」「..」「/」「*」と要素名の組み合わせですね。
これまた私の認識とは違います。ロケーションパスの基本は：
/」/」以上の三つの組み合わせで、さらにロケーションステップは：
の三つで構成されている、と考えるのが基本かと思います。最小単位は「軸とノードテストのみから成る単一のロケーションステップ）」です。また、ノードテストは「要素名」ではないです。*等のキーワードか、あるいはQNameです。
と、ここまではジャブ。基本をおろそかにして省略文法を「基本」だと考えているとXPathには色々と罠があります。
//data[2][memo]というロケーションパスについて、次のように解説されています。
文書内の２番目のdata要素を選択する。
ただし該当するdata要素が子要素memoを含まない場合、選択されない。
ダウト。
ルートノードの子孫ノード全てについて、その子供であるdata要素の内、二番目のものに絞込み、その中からmemo要素を子供に持っているものに絞り込みます。文書順（document order）で二番目とは限りません。因みに私なら/descendant::data[position() = 2][boolean(child::memo) = true()]というパスで解説します。
last() 最後のノードを返す。
これも間違っています。
まず、XPathのビルトイン関数の中にノードを返却するものはありません。扱えるデータ型は前述の4つ。また、last()関数が返却するのは数値で、コンテクストサイズと呼ばれるものです。
述語を使うなら、XPathの基礎となっているコンテクストと、その言わばコンポーネントであるコンテクストサイズ、コンテクストポジション、コンテクストノード、関連付けられた名前空間くらいは、少なくとも意識している必要があると思います。
演算子を使用する際には注意する点がいくつかあります。 まず比較演算子のうち「<」「>」の文字は、「<」「>」と記述しなければなりません。
必ずしもそうする必要はありません。
not()を使う場合、()内に条件式を記述します。
not関数の引数はブール値です。条件式
?はそのブール値を表現するXPath 表現の一つに過ぎません。
ともかくXPathは色々な場面で使用する基礎的なものですから、きちんと仕様書を読むのが一番です。XPathには理念やら解釈なども存在しないので、やはり、仕様書を読むのが一番です。というか、解説を書くなら仕様書を参照すべきです（SHOULD）。2003-03-10現在、HTML文書としてぶっ壊れていますが、XMLパス言語 (XPath) Version 1.0という日本語訳もあるようです。
XMLマスター基礎講座（お世話になった書籍＆ページ）には仕様書が見当たらず例の@ITが挙げられていますが、私はあそこの記事に突っ込みのメールを送ったことがあります。「/」をルート要素と説明していたからです（修正され済み）。日本の企業サイトが解説しているものには色々と違和感のある記事が多いので、突っ込みを連載企画にしようと思った程ですが、面倒なので止めました。営利系がどうなろうと知ったことではないのですよね。
mailtoリンクを見分ける @ 思考/謎で、Mozillaのユーザースタイルシートでmailtoスキームでリンクしているアンカーを見分ける方法が紹介されていますが、ふと思いついて私もInternet Explorer6 にて同じようなことをやってみました。
a要素のhref属性のURIがmailto:スキームを持っているなら、文字色を黒（#000）、そうでないなら白（#fff）にします。いやこれでは役に立たないのですが、取り敢えず例として。
何を今更expressionといった感がありますが、thisキーワードがセレクタで表される要素オブジェクトになっていたというのが発見でした。もっと早く気づいていれば……
expressionについてはsetExpressionを参照。
ということは、URIがhttp:等のスキームコンポーネントを持っていて、かつdocument.domainを含まないなら、外部サイトへのリンクであることが推測できるかもしれません。……結局そのくらいしか思いつきませんでしたが、まあ一応。そもそも、外部サイトだろうと内部サイトだろうと、あまり関心がないというか。
明らかにURLといってよいものをURIと記述していた部分をURLに修正……しようと思ったのですが、abbr要素としてマークアップしていなかったので放置することにしました（駄目）。XSLTスタイルシートで書き出している部分は、PURLだったりしますので、これは「Locator」というより「Name」、URNなのではないかな、と。でもPR PURLはURLのような気もします（参照：URN (Uniform Resource Name) について-- ごく簡単なHTMLの説明）。
と、ここで誠に残念な記事を発見してしまいました。
URI部分のない（#fragidだけの）URI参照は、その文書の「見え方（view）」を変更するものであるとされています。
次の一節をどう読むと、「見え方（view）」を変更するものであるとされています
などと解釈できるのでしょうか。
RFC 1808 (Section 4) defined an empty URL reference (a reference containing nothing aside from the fragment identifier) as being a reference to the base URL. Unfortunately, that definition could be interpreted, upon selection of such a reference, as a new retrieval action on that resource. Since the normal intent of such references is for the user agent to change its view of the current document to the beginning of the specified fragment within that document, not to make an additional request of the resource, a description of how to correctly interpret an empty reference has been added in Section 4.
ここではフラグメント識別子のみで構成されたURI参照の「定義」ではなく、その一般的な目的（normal intent of such references）が述べられているだけです。不適切な引用のような気がします。私ならこちらを参考にします。
The semantics of a fragment identifier is a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type [RFC2046] of the retrieval result. The character restrictions described in Section 2
（フラグメント識別子の意味は、参照に用いられたURIの形式に関係なく、取得動作の結果となるデータの性質である。それゆえ、フラグメント識別子の形式と解釈は取得結果のメディア型[RFC2046]に依存する。文字の制限はSection2で説明したとおりである。）
メディア型依存ということで、RFCのこの文書を根拠としてURI参照の具体を定義することは無理そうです。メディアを特定しないならThe significance of the fragment identifier is a function of the MIME type of the object
と、精々こう定義できる程度のものです（参考：Fragment Identifiers -- Axioms of Web architecture）。
ではXHTMではどうかといえば、XHTML 1.0: The Extensible HyperText Markup Language (Second Edition)のC.8. Fragment Identifiersに、次のような記述があります。
In XML, URI-references [RFC2396] that end with fragment identifiers of the form "#foo" do not refer to elements with an attribute name="foo"; rather, they refer to elements with an attribute defined to be of type ID, e.g., the id attribute in HTML 4.
「XMLでは、フラグメント識別子で終わるURI参照はID型として定義された属性をもった要素を参照する」とあります。HTML4では参照という単語は使われず、「name属性やid属性を持ったアンカーを示す」という程度の意味になっていますが、viewを変更するとった具体的な表示方法について定義した記述は見つかりませんでした。もしあったら「HTML4 is crap」と叫んでしまうところでした。
文章の読み方という点で見れば、ユーザーのアクションによってviewを変更する＝異なるポジションに移動するのも、やはりハイパーリンクですね。
異なるポジションに移動する
というのは、ある特定のメディアに依存した参照行為の一つの手法ですが、XLinkのように、「アクション」をリンクに含んでしまうのは大反対です。もし、ユーザーのアクションによって異なるポジションに移動するのが「ハイパーリンク」であるならば、「<a href="http://example.com/">ここをクリック</a>」をクリックして移動する行為も立派なハイパーリンクになってしまいます。ユーザーのアクション
を明確に示したクリック
、そしてそれをハイパーリンクとする為に、aタグでその文字列を括るのです。こんな自然な行為があるでしょうか。
リンクのセマンティクスに「アクション」を含めてしまうと、このようなメディア依存なリンク（例：ここをクリック）、あるいは、ユーザーの自由を侵害するリンク（target="_blank"）を含んだHTML/XHTML文書が大量に生産されることになります。その時になって初めて、具体的かつ詳細なアクセシビリティガイドラインの普及に躍起になるのと、リンクの意味からアクションの部分を最初から切り離しておくのと、どちらが良いでしょうか。「何故そのアクションを起こす必要があるのか」その理由を意味付けしてやれば機能的には同じ物を提供できるはずです。「何故文字を太くしたいのか」「強調したいからさ」
そういった意味で、XLinkの「behavior attributes」のshow属性などはかなり有害だと思います。
要するに、参照の性質を示せば良いところを、具体的なアクションを定義する形にしてしまっているのが駄目なのです。ユーザーエージェントは、参照の性質を知ることが出来れば、新しいウィンドウで開くかどうかを決定する有益な情報をユーザーに提供することが可能です。それで十分です。一方、xlink:show="new"では、参照の性質を伝えませんから、新しいウィンドウを開きたくないユーザーは、一律にこのアクションを拒絶する設定をするかもしれません。どちらがより良いでしょうか。
特定のメディアの特定の環境向けにこういったアクションの具体を定義する言語があっても良いとは思いますが、XMLのリンク一般を叙述する言語に、そのようなものは必要ないと考えます。
例えばfooという要素があり、id属性を持っているときにはcomplexTypeな型を持っており、ref属性を持っているときには空要素であるとすると、XML Schemaではどういう風に書けば良いのでしょうか。
XML Schemaのスキーマを定義するXML Schame文書を調べてみました。XML Schemaのelement要素が正にそれなのです。
……。
こいつは私の理解力の限界点に近い気がします。何度見てもいまいち釈然としませんが、element要素をローカルな要素として二通り宣言している辺りで実現していそうなことは、ボンヤリと分かった気がします。もう少し修養が必要なようです。
面白そうなURIを見つけたので参照してみました。
Someday a schema for XSL Transforms will live here
容易でないことは確かに想像できますが、期待していただけにかなりがっかりしました。
やっぱり何度見ても分かりません。というか、ローカルに宣言されたelement要素の型を見ても、ref属性とname属性の共存を許可しているようにしか見えませんでした。
実際、<xsd:element name="foo" ref="foo" />なる要素をもったスキーマ文書自身を検証してみたのですが、何も文句を言われませんでした。
持っている属性によって型を変えるなんて芸当は、XML Schemaには無理なのでしょうか。とりあえず私には分かりません。
XML Schemaに限った話ではないのですが、XMLでスキーマが定義されているということは素晴らしいことなのです。どういうことかというと、スキーマというのは本質的にそれ以上ないほど精密かつ正確なリファレンスなのですが、人にとって理解し辛いのが珠に傷です。 しかしXSLTでお好みの構造を持ったHTML文書か何かに適当に変換してやることで、その精度を微塵も損なうことなく読みやすいドキュメントにしてやることが出来るわけです。リファレンス本等々は、少なくとも構文を学ぶ上では一切必要なくなります。たった一つのXSLT文書を用意しておくだけで良いのです。XML Schemaの場合、適切な位置に詳細なannotationが用意されていれば、もはや解説本や解説サイトが不要になります。自分の好みの、一貫した体系でXML応用言語を効率的に学ぶことが可能になるのです。
従ってスキーマ言語の冗長性は大いに結構な話で、可能な限り豊富な意味付けをして頂きたいと思っています。将来、RDF/XMLでXML Schemaを再定義してもらっても良いくらいです。
やはり一番良い修養方法は、ゼロから言語を設計してやることだと思います。というわけで勢いだけでCSS1をXML化してみようと思い立ちました。これは結構前からやりたかったのですが、CSSのレベル毎の管理やブラウザ対策用プロパティ等の管理、共通プロパティグループの定義等々が可能になります。CSSは見た目シンプルですが、実際には値に多くの型が存在していますし、運用する際にはバグに付き合った解も紛れ込ませなければなりません。専用のツールでもない限り、管理がとても大変です。
尤も、頻繁にCSSを破棄して新しく作る場合には関係ない話ですが、少しずつ改良を加える場合にはだんだんスパゲッティ化してしまうのです（参照：[croix.css] 笑）
そのスキーマとインスタンスを利用することから：
等々の見返り（副産物）を期待しています。
実はスキーマは物理量的には殆ど完成していて、プロパティ（要素として表現）の型定義は書き終えました。CSS1の仕様書に全部書いてありますから機械的な作業で済んだわけです。後は構文をXMLでどう表現するかというところで躓いています。あるセレクタにプロパティを与える方法の一つとして、外部からプロパティのグループを参照させる形を取れるようにしたいのですが……。