HTML文書作成日記

2 周年なのでひとりえっち日記♪デー

記述年月日

2004年04月01日

なんか日記を公開し始めて 2 周年とかそんな感じなので、ひとりで CSS を拵えてというか今作ったってものでもないですけれども、まあ作ってしまったものなので推奨 CSS とかにしてみました。どうもすみません。次回の更新と共に引っ込めますゆえ、当方が提供している CSS を適用しての閲覧の際に生じる不具合につきましては、取り敢えず泣き寝入ってください。

ちなみに「HTML文書作成日記」の略称が「えっち日記♪」なのであります。省略すると音符記号がつくのがポイントです。思わせぶりで下品な略称。これを HTML 的に表現すると <abbr title="HTML文書作成日記">えっち日記♪</abbbr> とでもなりましょうか。さておき、えっち日記♪の記念祭をひとりで行っているわけですから「ひとりえっち日記♪デー」となるわけですね。

そういえば本日はエイプリルフールですね。御粗末。

XSLTのお勉強メモ

記述年月日

2004年04月01日

わざわざとメモらずともすぐに見つけられる記事なのですが、いちおう。マーク付けで示しているとおり、以下は順序不同です。

• XSL 変換 (XSLT)
• XSLTに関する記事
• XSLT & XPath 目次
• XSLTに関する記事 - agenda - Personnel
• ねこめしにっき見出し一覧 (XSLT)
• XSLTについての湾岸日記
• サンプルで覚えるXSLTプログラミング

今までは何のことかさっぱり理解出来なかった記事だったのですが、自分でどうこうするようになってからは、記述されていることがなんとなく理解できるようになりました。なんというか、ひとつの動機として、記事を楽しむために学んでいるような気がしてきました。それを否定する気はないですし、不純な動機だとも思いませんけれども、いくぶん手段と目的が倒錯してしまっている感が。

この日記のコンセプトのひとつは、「先人の知識に追いつけ」です。今そうなりました。行く道はある程度整地されているので、後から歩む方は楽なのが良いところ。

ところで、未知の技術や知識・言語などは仕様書に目をとおしただけでは扱えるようにならないのですね。実例でもって、「こうするとこうなる」という大まかなことをまず学び、少しずつ理解を深め、それから仕様書に目を通しても遅くはない気がしました。もちろん第一に仕様に目を通すのも当然アリなのですが、ある程度の知識を有してからの方が学習には効率的なような。あ、仕様書は未読でした。

それと、今気付いたというか気になったのですが、「先人」と呼称してしまうのは語弊があるような。もしこの言い回しに違和感を覚えた方がいらっしゃいましたら、脳内置換を宜しくお願いします。

日時表記の国際標準

記述年月日

2004年04月01日

この日記では SSI を使って更新日時を出力しているのですが、ここでふと「 HTML もきちんとしたルールがあるのだから、日付 (日時) のきちんとしたルールもあるのではないか」「もしあるのであれば、国際標準にそうものの方が好ましいだろう」と思い立ち、少し探してみたところ、やはり日付表記も国際標準があるようでした。

以下は日付の表記に関するノートから。

W3Cのノートで示されている表記法はW3C-DTF（もしくはW3CDTF）と呼ばれ^[*注]、次の6通りのフォーマットがあります。

(1) 年のみ

YYYY（例：2001）

(2) 年月

YYYY-MM（例：2001-08）

(3) 年月日

YYYY-MM-DD（例：2001-08-02）

(4) 年月日および時分

YYYY-MM-DDThh:mmTZD（例：2001-08-02T10:45+09:00）

(5) 年月日および時分秒

YYYY-MM-DDThh:mm:ssTZD（例：2001-08-02T10:45:23+09:00）

(6) 年月日および時分秒および小数部分

YYYY-MM-DDThh:mm:ss.sTZD（例：2001-08-02T10:45:23.5+09:00）

上記のフォーマットで変数として表記しているアルファベットは、一般に使われるようにYMDがそれぞれ年月日、hmsがそれぞれ時分秒を表す数字を意味します。小数点以下の秒を表記するばあい、桁数に制限はありません。TZDはタイムゾーンを示す部分で、UTC（協定世界時＝グリニッジ標準時）との時差を+09:00などとして示すか、UTCで表記していることを示す Z を記述します。また、年月日と時分秒はアルファベットの T で区切ります。

この表記法は曖昧さなく、かつコンパクトに日時を示すことができ、またソフトウェアでの処理も簡単であるというメリットがあります。[HTML4]では、%Datetime;（ins/del要素タイプのdatetime属性）は、このW3C-DTFを用いるようセクション6.11で示しています。

で、ここで挙げられているうちの年月日および時分秒を SSI を使って表記するならば、configコマンドを使っての日付フォーマット (<!--#config timefmt="......" -->) は以下のようなものでいいのだろうか。

• <!--#config timefmt="%Y-%m-%dT%X+09:00"-->

と設定してみたものの少々の不安が。というのはつまり、タイムゾーンを表す +09:00 はサーバ側に頼らず手書きでいいのだろうかといったところ。しかし悩んだところで答えはでるはずもなく、出力されるものは表向き国際標準なので、何方かにご指摘されるまではこの形で出力することにしました。

話が前後してしまうのですが、正しい出力方法を探していたところ更新時刻取得方法 - わっちりんく(す)という記事を見かけ、そういえばこの日記も WWC でチェックしている方がいたような、などと思い出したので、ことのついでとばかりに head 要素内にも最終更新時間を出すようにしてみました。

この形式で記述しておくと、WWWC でチェックタブの下にある「META タグを使ったチェックを行う」をチェックして

タイプ

http-equiv

タイプ名

Last-Modified

コンテンツ

content

と設定すれば更新時刻がチェックできるようになるのでオススメ。

だ、そうです。 meta 要素でもってチェックをすると当方のアクセス解析にも引っ掛からないのでオススメ。と豪語するも、実は引っ掛かってしまう罠だったり…… (たぶん) 。嘘吐いてどうもすみませんでした。嘘というか、無知ゆえに。

仕様書は辞書

記述年月日

2004年04月02日

今までは「仕様書は説明書みたいなものだ」と思っていたのですが、仕様書に目をとおしたからといって、たとえば HTML をきちんと使えるようになるかというと、そうでもない。もちろん、目をとおしていない人と目をとおした人では目をとおした人の方がきちんと使えるとは思います。しかし、仕様書に目をとおしただけできちんと使えるかというと疑問があるのです。そうすると、「仕様書 = 説明書」というのは些か怪しい。では、仕様書を上手いこと換言すると何になるだろうと考えたわけです。

おそらく中略。

HTML 4.01 の仕様書で言うと、それには意味と簡単な範例が示されているので、仕様書を敢えて換言するならば「辞書」が妥当だろうとなったわけです。脳内で。辞書にいくら目をとおしたとしても、「語句そのもの」の意味はわかるようにはなるけれども、「文章そのもの」がきちんと書けるようになるわけではないですから。といった感じで。

細かなことはまた後日書きます。たぶん。後日書くと公言して書いたためしはないのですけれども……。というか、仕様書は辞書だというのはひょっとして自明だったりしますか?

馬から落馬と似た感じ

記述年月日

2004年04月02日

• Google 検索: 指を突き指

一概に重複しているとはいえませんけれども。いや、でもどうなんでしょうか。しかしたとえば「足の指を突き指」。この言い回しは「足を突き指」となりますか? 「足」には指も含まれているとはいえ、これはヘンだ。そんなわけで、一概に重複しているとはいえないような、と。ちなみに「ヘン」といった主だった根拠は直感的に、です。ためしにGoogle 検索: 足を突き指を参照してみたら、数が驚くほど少なかったというのもあり。ところで、「どうだっていいよ、そんなこと」という幻聴がすごいのですが気のせいですか。

以上が主文。以下は余談。

朝起きたら右手親指を突き指していました。「なんだコレ」ってくらい痛い。具体的に言うとライターを着火できないくらいに。っていうか寝ている間に突き指なんてするんですか。まあ実際したんですけど。

僕の利き腕は右なので、ペンを使って文字を書くなんてことも出来ないし、タイピングも出来ない。箸もロクに扱えないので食べるのにも困る。で、いい機会なので左手でいろいろとチャレンジしてみたのですが、やっぱり上手いこと行かないし、自動販売機やらなんやらは基本的に右利きに優しい作りになっているので、ここでもまた困る。何で人は右利きが多いんですかねというお話 (脳構造が要因ですかね? ) 。あと、左利きの人はよくもまああんな難しいことを簡単にやってのけているなと感心した。左利きすげえ。やつらの器用さは尋常じゃない。

ちなみに利き目と利き足は左です。そのくせ漠然と「どっち利き? 」と尋ねられると間髪居れず「右利き」と答える人間です。どうでもいいなコレ。

「常識」で通じないから話し合うのでは

記述年月日

2004年04月02日

共通認識がなければお互い何を言っているのか、何が言いたいのかがわからないような。

インラインフレーム内で他サイトを表示するのは「リンク」か「盗用」か？という議論で徳保氏が絡んだのが理由のようです。個人的にはそういった定義次第の議論以前に「常識的に×だろ」っていうだけの話のような気がしますけど。

その「常識的に×だろ」で話が解決しない、つまり常識という言葉で片付かないから意見交換しているのではないのでしょうか。常識と言うのはある特定の価値観を持っているもの同士でしか常識ではないですし、また、そこから鑑みると、価値観によっては常識ではなくなってしまうという危うさを持っている。さらに言うと、場を構成する人々によっても常識は変わってしまう。だから少しでも特定の価値観からみての常識に左右されないよう、話し合いの中核を担う言葉を定義として設け、その前程でもって話を進めるのでは。

言ってしまえば、「常識」で片付くのならば話し合う必要性も生じませんし、「常識」では片付いていないから話し合っていると思うのです。共通認識であるはずの「常識」では片付かないからお互いの認識のズレを埋めるため、あるいはお互いのズレがどこにあるのかを認識するために話し合い、そしてそのズレを認識した上で何かしらの結論などを導こうとしているのではないのでしょうか。

以下は共に国語辞典 英和辞典 和英辞典 - goo 辞書から。

じょうしき　じやう― 0 【常識】

• 〔common sense〕
• ある社会で、人々の間に広く承認され、当然もっているはずの知識や判断力。
  • 「―では考えられない奇行」
  • 「―に欠ける」
• 「共通感覚」に同じ。

きょうつう-かんかく 5 【共通感覚】

• 〔哲〕 五感の根底にあってそれらに共通するものの感覚。また、ある社会で一般に通用する判断力、すなわち常識をも意味する。

つまり、繰り返しになってしまいますが、対話を有していること自体が共通感覚が導かれていないので、一方的に常識だと思っていることは常識ではないのでは、と。だから、ある一定の場においての話し合いに必要になってくるであろう言葉の定義を軽んじ、「常識的に×だろ」と仰ってしまうのは些か短慮なのではないかと思いました。お互いの認識の上では常識ではないのですから。

具体的に言うと、何故常識的に×なのですかと疑問が残るのです。そしての返答が「だって常識だろ」では、それが常識ではない人間からすると根拠が理解ができないのです。なので、発言者にとっては説明をする程のものでなかったとしても、「常識」という言葉で片付けてほしくないのです。

ちなみにこの文章で「常識」という言葉は見出しも含めて 22 回登場しました。このパラグラフを含めると 23 回。過剰なまでの反応。

猫アレルギーだニャ……

記述年月日

2004年04月02日

• 国語辞典 [ にゃあ ]の完全一致での検索結果
• 国語辞典 [ にゃあにゃあ ]の完全一致での検索結果
• 国語辞典 [ にゃ ]の完全一致での検索結果

何でもあるんですねという印象。

Re^2: xyzzy で < とかって一発挿入できないんですか

記述年月日

2004年04月12日

以前に「 xyzzy で < とかって一発挿入できないんですか」なんて放言をしたのですが、先日Junklineの Asano さんとその周辺の方々 (と一緒くたにしてしまいどうもすみません) に「できますよ」と間接的にご教示いただけました。どうもありがとうございます。本来ならば真っ先に謝意を述べなければならない人間なのですが、今更ながらに、しかも間接的にですみません。

……「だってコメント投稿恐いんだもん」っていうアレでございまして。

• Junkline - Re: xyzzy で < とかって一発挿入できないんですか 1
• Junkline - Re: xyzzy で < とかって一発挿入できないんですか 2
• 朝顔日記　2003年12月　03年12月22日　続・よく使う置換をダイアログから

a 要素のメモ

記述年月日

2004年04月12日

• <a href="http://foo.com/" />

こんな感じで書いて、それでスクリプトかなんか経由して当該文書の title 要素を取得し、実際に公開される文書では前述の a 要素を <a href="http://foo.com/">取得した title </a> と置換されたら素敵だと思った。と思ったけれど、そんなことをするくらいならば素直にタグを使って示すことをしないでふつうに URI をベタ書きして title を取得してくればいいんだろうなと同時に思った。

• <a href="http://foo.com/">http://foo.com/</a>

この置換はダメ。

過ぎると伝わらない

記述年月日

2004年04月12日

今更ですが。

• ANNEX-DK: legend問題
• ANNEX-DK: legend(3)

私はStrictなHTMLを推進する人はこんな感じだ、というイメージを持っています。ようするに偏見です。私の思う「StrictなHTMLを推進する人」は、理論派で、議論をすることに慣れています。また、馴れ合いが嫌いで、歯に衣着せずに言いたいことをズバっと言います。さらに、完璧主義者で、間違ったことが大嫌いです。

はっきり言って、そんな人物に目をつけられたらと思うとゾッとします。Webの世界のどこかに居る「理論武装兵」に対する恐怖です。

ある特定の価値観を有していない人からすると瑣末なこと (瑣末な間違い) であっても、ある特定の価値観を有している人からすると好ましくないことがあって、そういった主張を是正しようとすると「正しいこと」という後ろ盾もあり、そして理論派で、議論をすることに慣れている (ように見受けられることが多々ある) ので、是正された方からするとある種詰問とも捉えられかねないのだろうな、と思う。

もちろん是正に努めている方々全てが理論派で、議論をすることに慣れているわけではないにせよ、 2 ちゃんねるが近いということも一因なのだろうけれども、ちょっとした言及であったとしても内容如何によっては話題の広まりが速いこともあって、そこから受ける印象もまた強烈だから言及された方にはあまりいい顔をされない。「たいした間違いでもないじゃん。何でこんなに強烈な反発を食らうの? 」と。

HTML などに興味の無い方からするとStrict HTML陣営な人たちが、傍から見て明らかに「気持ち悪い」という印象を与えてしまうのは致し方ないだろうなとは思う。興味が無い方からすると文法なんてものはどうでもいいことなので、「 HTML 如きで躍起になって以下略」みたいなふうに。言ってしまえばオタクだし。

あと、きちんとマーク付けされている文書というのは利用者からすると扱いやすい。簡単にいうと、利用者が用意した CSS を適用して閲覧すると、一見しただけでそれがどのような要素であるかわかるようにできるので、利用する上で負担が減る。

文字列の出現順位

記述年月日

2004年04月12日

上記というのは上または前に書いてあることという意味もあって、下記というのはある記事の後に書き記すことという意味があって、左記というのは縦書きの文書の左の方。すなわち後の方に書いた部分らしく、ついでに右記の意味を調べてみたら辞書には載ってなかったのでありました。普段は WWW の辞書を利用しているのですがそれだけでは不安だったので、ためしに手元にある辞書も調べてみたのですが、やっぱり載っていませんでした。というか、久々に書籍から引いたのですが、ものすごく面倒だった。

My is ann Pen!

記述年月日

2004年04月12日

英文法間違っちゃった人。

• KKC

あんたの英語の方が笑えるよって表題、いいなあと思った。

img 要素の longdesc 属性

記述年月日

2004年04月14日

「へー。そんなのあったんだー」というだけの話ですが。そんなわけで仕様を引いてみる。

longdesc = uri [CT]

この属性は、当該画像の長文説明へのリンクを指定する。この説明は、alt属性を用いて提供される短い説明を、補完する必要がある。画像がイメージマップと結び付いている場合、この属性はイメージマップの内容についての情報を提供する必要がある。サーバ側イメージマップにおいては特に重要である。IMG要素はA要素の内容となり得るので、ユーザエージェントの機構に関して、まず先に「長文説明」リソースへアクセスするためのユーザインターフェイス機構は、後にhref属性のリソースへアクセスするための機構とは異なっていなければならない。

引いた仕様だけでは幾分わかりづらい感があるので具体例は以下を参考に。

• <img longdesc=...>について

ここからはちょっと怪しい脳内換言と疑問の提示。

img 要素というのはインライン要素であるのでその代替テキストも HTML の観点から考えると必然的にインライン要素となってしまう。また、その img 要素を包括しているブロックレベル要素如何によっては ( HTML の観点からみると) alt 属性値がおかしなことになってしまう。具体的には p 要素に包括された img 要素の alt 属性値が ( p 要素は他のブロックレベル要素を包括できないため) p 要素以上のブロックレベル要素であってはおかしい。

しかしイメージが提供できる情報というのは大きく、 alt 属性値は時として複数のブロックレベル要素ともなり得るわけだ。ただ、前述したように img 要素はインライン要素であるので、その代替とされている情報を (あるいは、その情報がブロックレベル要素であったとしたならば) alt 属性値として提供するには無理があることが間々ある。

で、「そういったケースでも用いてよろしいのでしょうか」という疑問。というか、主だった用途は図解の説明とかそんな感じがするので、わりと的を外れている疑問っぽいのですけれども。なんにせよ自分を納得させるための拙い理屈なだけなので、追及されても困ります。←弱腰。

あと、「ブロックレベル云々であってはおかしい云々」というのはあくまでも HTML 文書の枠組みで考えたら、で。つまり既に存在しているテキストをマーク付けするということを考えなければ問題が派生する余地はないので、マーク付けすることを想定した文書作成するにあたりという感じで。まあ HTML 的に考えなければブロックレベル要素がどうたらなんて文言は出るわけがないのですが。

……で、暇つぶしにウェブコンテンツ・アクセシビリティ・ガイドライン1.0 HTML技術書を読んでいたら、当然の如くというかなんというか、longdesc 属性の扱い方への言及があったので、自分用メモとして引用してみることにする。以下は7.2 画像に対する長い説明から。

短い同等の役割を果たすテキストでは画像の役目や働きが十分に伝えられない場合は、longdesc属性で指定するファイルで付加的な情報を提供してください。

【例】

   <IMG src="97sales.gif" alt="1997年の売上" 
        longdesc="sales97.html">

sales97.htmlの内容：

図表では、1997年の売上の推移を示してします。図表は
棒グラフになっており、月ごとの売上の伸び率を示して
います。1月の売上は1996年の12月にくらべて10%アップ
していますが、2月は3%のダウン・・・

【例終了】

longdesc属性をサポートしていないユーザーエージェントのために、画像の横に説明へのリンクもつけてください。（【訳注】このリンクを示す場合、英語の場合では一般に "Description" の [D] が使われています）。

【例】

   <IMG src="97sales.gif" alt="1997年の売上" longdesc="sales.html">
   <A href="sales.html" title="1997年の売上の図表に関する説明">[D]</A>

【例終了】

だ、そうで。ところで、自分で書いたところを改めて読み返してみたらちょっと酷い文章だと思った。ブロックレベル要素とかインライン要素だとかを考えずに、素直に「画像に対する長い説明」で落としておけばよかったような。こんな放言や妄言を繰り返していたらいつか怒られる (既に相手にされていないのならば安心) 。

余談。アクセシビリティだとかはよくわからないのですが、 HTML 文書の利用性を考えそして意識して文書を作成すれば、ガイドラインを参照せずとも自然とよい文書が出来上がるような気がしました。自分がそれに努めているかは別ですけれども。まあ、なんというか文章力にいくらか難がある僕はそんなことを考える以前に文章の構築能力を培えという感じではあります。

XSLTのお勉強メモ #2

記述年月日

2004年04月16日

• カテゴリ別の記事見出し一覧 (XSLT)

クリッピングだけでは知識がつきませんよと自分に言いたくなってきた。ただまあ、興味がある方にとっては有用なリンクにもなるはずなので良しとする。

差出人 venus1_jpjp@yahoo.co.jp からのメール

記述年月日

2004年04月17日

単なる迷惑メールでしたというオチです。

ヨロシクお願いしますm(--)m→ http://www.venus-net.net/?Y17 あかね☆

だそうで、あかねさんに心当たりがない僕は取り敢えずとばかりに Google を使って検索してみたところ、単なる迷惑メールだということが判明した。まあそれは別にいいんだけれども、星や音符記号、顔文字などが添えられている文章というのはなんだか腹立たしい♪ ちなみに差出人のメールアドレスへの心当たりの有無に関わらず、僕は受信したメールアドレスを Google などで検索するのがクセなのであります。

HTML 4.01 Transitional が制定された理由

記述年月日

2004年04月18日

相変わらず引用で済ませてしまいますが。

HTML には様々な規格 / 勧告がありますが、特別な理由がなければ HTML 4.01 strict か XHTML 1.0 (或いはそれ以上のバージョン)として宣言することをお奨めします。「HTML 4.01 Transitional でもいいじゃないか」と仰る方もおられるでしょうが、HTML 4.01 Transitional はそもそも、制定時に「CSS は僅かのブラウザでしかサポートされていない」という事実に基づいて制定されたものです。CSS をサポートしたブラウザが大勢を占める現在、HTML 4.01 Transitional として HTML 文書を作成することは、文書利用者 / 作成者双方に不利益を与えることになります。

かなり前に読んだ文章だったのだけれども、その後 URI を失念してしまったもので残念な思いをしていたのですが、ふとしたきっかけで再び閲覧することができたのでした。初恋のあの子にあえたとかそんな感じですか。たぶん違うな。

さて、HTML 4.01 Transitional として HTML 文書を作成することは、文書利用者 / 作成者双方に不利益を与える根拠はなんだろう。ふつうにマーク付けしていけば自然とある程度は Strict なマーク付けが施された文書になるはずだ。そもそも非推奨なタグが使えるからといって、使わなければならないわけでもないし、きちんとした入れ子を作ることもできる……のだけれども、そうすると、結果的には Strict なマーク付けということになるわけだから、文書型を Transitional とする必要がなくなる。逆に言うと文書型が HTML 4.01 Transitional とされている文書は好ましくないタグが用いられている場合や、おかしな入れ子状態にある (あるいは入れ子になっていない) 要素の存在があったりもするので、そこから考えると不利益を蒙る結果にもなるのか。なるほど。

ある程度は Strict なマーク付け……

• 見出しレベルやタグの入れ子がきちんとしていて、匿名ブロックが存在しない ( div タグを取っ払っても文法違反にならない) マーク付け。
• 行内の文字列をきちんとマーク付けしていなくても、前述にそっていたら「ある程度は Strict なマーク付け」となる。
• Valid HTML/XHTML - I'll sleep on it.で挙げられている例と似た感じで、中黒と <br> でリストっぽく振舞わせていたりする文書はダメ。しかし HTML-lint で 100 点ではくても可。
• 言うまでもなく脳内定義。でも言う。

シリーズ! XML + XSLT 化までの道のり

記述年月日

2004年04月21日

最終的に WWW に公開するのは XSLT された HTML 文書になるわけですから、「XML + XSLT 化までの道のり」という表題はおかしいのですが、まあその辺りは脳内置換でゴニョゴニョしていただきたく。たぶん、 100 回くらいのシリーズものになります。あと基本的に個人的なメモなので文体もぞんざいになるかもしれませんし、語弊は誤認からくるアレもあるかもしれませんが、そのあたりもゴニョゴニョでお願いします。後日誤りに気付いたとしても修正はしない予定。それから、ご指摘を頂いても僕にはおそらく理解が出来ないと思うのでそちらの方も以下略。つまり全てにおいて不親切設計。

以上、免責。

で、エディタでは日付は一発で挿入できるわけだから、以下の ( XSLT で言うところの、ではなく単なる日記用の) テンプレートを呼び出す過程で DD 属性値も日付として付記すれば二度で間にならずに済むわけだ。とはいっても、今回やることは sect 要素を class 付き div 要素への単なる置換なのだけれども、取り敢えず第一歩として。まあいいか。以下、用意するもの。

XML 文書 (結構省略されてる)

• <document>
  • <sect DD="日付 (たとえば 22 ) "> ← DD 属性値は二桁の数字 (じゃなくてもいいんだけど) 。
    • …中略…
    </sect>
  • 以下 sect 要素の繰り返し。
  </document>

XSLT 文書 (ってのもヘンか)

• <xsl:template match="sect">
  • <div class="section">
    • <xsl:apply-templates />
    </div>
  </xsl:template>

しかしこの変換ではせっかく付記している DD 属性及びその値が無駄になってしまう。そもそも狙っていることは (現状の HTML 文書を) ある程度簡略化された XML 文書から現状と同等の文書を作ろうとしているわけだから、記述年月日を作らなければならない。 dl 要素として。というか今気付いたんだけど、 section 属性値も xsl:attribute を用いて作った方がいいのかな。いや……そうでもないかも。んー。でもそう考えたら、 div 要素も xsl:element で作るほうが妥当になってくる。あー、いや、違うな。現状であっているはず。まあいい。これについては後回し。どちらにせよ、これはアイデアの草案なのだから、清書するとき直せばいい。

そもそも、こんな置換をするくらいならば sect 要素をわざわざと明示せずに、構造化スタイルシートやフラットな文書を構造化(フラットな文書を構造化 その2) 、あるいはねこめしにっきで使われているsection.xslなどを再利用してしまえば済む話なのだけれども、それでは自分の知識にならないから躊躇いが。それならば自分でこしらえてしまえ良さげなのだけれども、現状の知識を総動員しても作れない。 </div> をアレする構文がさっぱりだ。

シリーズ! XML + XSLT 化までの道のり #2

記述年月日

2004年04月21日

免責はシリーズ! XML + XSLT 化までの道のりと同じ。

さて sect 要素の DD 属性値から現状と同じような構文を作ろう。 XML 文書は前述のと同じ。

XML 文書 (結構省略されてる)

• <document>
  • <sect DD="日付 (たとえば 22 ) "> ← DD 属性値は二桁の数字 (じゃなくてもいいんだけど) 。
    • …中略…
    </sect>
  • 以下 sect 要素の繰り返し。
  </document>

XSLT 文書 (ってのもヘンか)

• <xsl:template match="sect">
  • <div class="section">
    • <xsl:call-template name="date" /> ←増えた。 date という名前付きテンプレートをアレする。
    • <xsl:apply-templates />
    </div>
  </xsl:template>
• <xsl:template name="date"> ← date という名前が与えられたテンプレート。
  • <xsl:element name="dl"> ← dl という要素を作る。
    • <dt><xsl:text>記述年月日</xsl:text></dt>
    • <dd><xsl:value-of select="@DD" /><xsl:text>日</xsl:text></dd> ← DD 属性値を当てはめる。 @ が付いているのは属性名だからとかそんな感じ。 XPath よくわかんない。
    </xsl:element>
  </xsl:template>

で……というか、また気付いてしまったんだけど <xsl:element name="dl"> に包括されている <dt><xsl:text>記述年月日</xsl:text></dt> とかも dl 要素を作るのと同じように xsl:element を使って作るべきなのか、とか悩み始めた。ウンザリしてきた。っていうか、なんか中途半端だ。これも後回し。さて置き、いちおうこれで sect 要素の DD 属性値を dd 要素の一部として変換することは出来たのですが、これでもまだ西暦と月がないのでいくらか不完全なわけです。実際に出力されるのは <dt>記述年月日</dt> <dd>DD日</dd> なわけですから。ちなみに sect 要素の DD 属性と dd 要素がかぶっているのは偶然です。

さて、西暦と月も前述と同じように dd 要素の一部として出力するにはどうしたらいいのかとの問題です。

いちおう目指しているところは、ひと月分の記事が書かれている XML 文書を XSLT して……というわけなので、同一の日記用 XML 文書に収められている記事が書かれた年、そして書かれた月も必然的に同じになるので、いちいちと sect 属性に西暦と月を設けるのは些か冗長なようなになるわけです。ではどうするか。親要素の属性に年と月を書いて、そこから取得すればいいわけですね。ルート要素でもいいのですが。っていうかなんで「です・ます」調になってるんだ。

XML 文書 (結構省略されてる)

• <document YYYY="2004" MM="04"> ← YYYY 属性と MM 属性が増えた。
  • <sect DD="22">
    • …中略…
    </sect>
  • 以下 sect 要素の繰り返し。
  </document>

XSLT 文書 (ってのもヘンか) <xsl:template match="sect"> は一緒。

• <xsl:template name="date">
  • <xsl:element name="dl">
    • <dt><xsl:text>記述年月日</xsl:text></dt>
    • <dd><xsl:value-of select="//@YYYY" /><xsl:text>年</xsl:text><xsl:value-of select="//@MM" /><xsl:text>月</xsl:text><xsl:value-of select="@DD" /><xsl:text>日</xsl:text></dd> ←なんで /@... じゃダメなのかよくわからない。
    </xsl:element>
  </xsl:template>

以上のような構文から変換をすると <dd>2004年04月22日</dd> となるわけだ。めでたし。 XSLT の解説記事と誤解されて、トンデモ記事として晒し挙げられるのも嫌だったので「です・ます」調をやめてみた。謎。しかしまあなんというかあれだな。年や月、日付すらも明示せずに変換する過程で挿入すればいいような気がしてならない。けれども、書いたその場で変換するわけでもないからなあという感じ。

あと、ぼんやりと考えていたらわざわざ名前付きテンプレートを作成して <xsl:call-template name="date" /> で以下略というのは無駄というかヘンな感じがしてきた。 <xsl:template match="sect"> の中でどうこうしてしまった方がいいのかもしれない。わからないけれど。

シリーズ! XML + XSLT 化までの道のり 番外編

記述年月日

2004年04月21日

たとえば、 quote タグなんてものをでっち上げて、変換過程で blockquote 要素にしたり q 要素にしたりとか出来そう。包括している子要素によってどうこう、みたいな。まあ、そこまでする必要もないんだろうけれど。あと、引用要素の cite 属性から要素を作ることもできるか。しかしこれは個人的な嗜好から JavaScript を頼りにしたいところだ。

それはさて置き、やりたいことを全てやる知識を得るにはもうしばらくかかりそうだなあ。今やっていることはなんというかひたすらテンプレートを作って当てはめて……ってなわけで、要するに div 厨と似た感じだし。それと、現状ではただアイデアが散在しているだけだから、それらをきちんとした筋道に置き換えないことには。今月いっぱいが目処。

シリーズ! XML + XSLT 化までの道のり #3

記述年月日

2004年04月22日

予告。「わからない」というオチです。

そんなわけで sect 要素を div 要素に置換し記述年月日を添えることに成功したのですが、これでもまだ不完全なのであります。端的に言ってしまえば、置換された div 要素に id 属性を添えたいのですね、僕は。

さてそうすると日付をそのまま id 属性値にしてしまえば良さげなのですが (というか、最初になにかの文字列を添えて) 、これだと同一の DD 属性値を持つ記事があった場合、記事の id 属性値がいちいち重複してしまうのでそのままでは使えない。この問題を解決するためには記事に番号を添えればいいわけです。できれば日付の後に番号を添えるのが望ましい。しかし、この番号をわざわざと手作業で添えていくのは手間の削減という観点から考えるとバカらしい話でもあります。なにより、番号を添える作業なんてものはどうみても機械処理の得意分野なわけですから (知らんけど) 、ここは番号を添えるスタイルシートを書いて済ませたいところ。

XSLT 文書 (ってのもヘンか)

• <xsl:template match="sect">
  • <div class="section">
    • <xsl:attribute name="id"> ← id 属性を作る。
      • <xsl:text>d</xsl:text> ←値の一番目に d って文字列を入れる。
      • <xsl:value-of select="@DD" /> ←日付を取得。上記とあわせると d日付 となる。
      • <xsl:text>n</xsl:text> ←続いて n という文字列を入れる。
      • <xsl:number format="01" /> ←これによって 01 から順に番号を振る。
      </xsl:attribute>
    • <xsl:apply-templates />
    </div>
  </xsl:template>

以上のスタイルシートで変換すると id 属性値は d日付m番号 となる。つまり id 属性値を半自動的に添えることができるのですが、このまま変換をしてしまうと、全ての sect 要素に番号を振られてしまう。やりたかったとこととしては、同一の DD 属性値を持つものに 01 から順に番号を添え、 DD 属性値が変化したらまた 01 に戻り……というものなのですが、その方法がわからないのでありました。なぜなら調べていないから。

ファイルの put を簡略化

記述年月日

2004年04月23日

• ThingamaBlog

ローカルで簡単に HTML 文書を作成して、ボタンひとつで FTP できるというツールです。この手のソフトはいろいろあるわけなんですが、ブログっぽいことをするのに向いているという意味では、たしかにこれは完成度の高いソフトだと思います。

紹介されているツールはいかにもブログっぽいもの向き (詳しく読んでいないのでわかりませんが) だったので、さて僕らのような日記をハンドメイドしている人間はラクが出来ないものか、やっぱり麦を食えということなのか、などと感じていたところだったのですが、実はそうでもなくてどうやら Windowsに付属している ftp.exe を使えばボタンひとつでファイルの put が出来そうです。こちらはバッチファイルを作ってという感じです。

• 朝顔日記更新の仕組み 「FTP はどうなっているのか」の項。
• もっと自動化

わかっているとは思いますが、細かなところの構文は各自の環境に合わせて。というか、個人的なメモとしてリンク。

更新されるファイルが単一程度ならばその都度にたとえば FFFTP などを使ってファイルを put すればいいのだけれども、一度にたくさんのファイルを put するようなタイプのサイトならばバッチファイルなどを作成してボタンひとつで任意のファイル群をサーバへ put するようにしてしまった方が手間がかからず都合が良い、とか。

言いたいことを要すると、 XML 文書を XSLT してたくさんのファイル生成し、そしてそれらを更新するならばという感じです。そんなことを視野にいれなければならない程まだ知識を有してはいないのですが。

ところでこの「 XML 文書を XSLT して〜」という技法 (?) の良いところは環境に依存せずに既存のブログツールやサービスなどと同等なことができるところであります。 MT やらなんやらの設置の可・不可はサーバに大きく依存する。双方の欠点はそれなりに知識がなければ実現不可能なところでしょうか。しかし MT やらは設置までの解説が親切なので、そう苦労はせずに試せるのが良いところです。と完璧なまでの余談。

シリーズ! XML + XSLT 化までの道のり 番外編 #2

記述年月日

2004年04月23日

関数の学習から逃避するように遊びにふけっている、というのが正直なところ。寄り道です。

はてなダイアリが自分にはごく身近に感じたので逃避がてらにはてなダイアリ要素 ( 要素名は htn です ) なんてものをでっち上げてみました。実際には使わないのでしょうけれども、要素や属性を生成する感じを掴むには良い題材かなと思ったもので。なお、注釈はごく私的な覚え書きなので正誤は微妙なところかもなので、ご注意ください。説明口調で書いているので誤解されるかもしれませんが、このシリーズは解説ではないです。しつこいようですが。っていうかシリーズて。

以下、ほぼ逐一といっていいほどコメントを添えているので少々煩わしく、また、わかりづらい感じもするかもしれませんが、コメントを削除し各要素毎に注目していけば簡単な構文です。などといいつつ自分でも消化し切れていない個所がいくつかあります。それについては後述します、たぶん。

XML

• <htn>klezer</htn>

XSLT

• <xsl:variable name="htnURI"> <!-- name 属性値は何でも (でもないですが、別に htnURI でなくても) 可。 -->
  • <xsl:text>http://d.hatena.ne.jp/</xsl:text> <!-- 実質的な (?) 変数値。 -->
  </xsl:variable>

• <xsl:template match="htn"> <!-- 変換元となる要素名 (ここでは htn ) とマッチするもの。 -->
  • <xsl:element name="a"> <!-- a 要素を生成。 -->
    • <xsl:attribute name="href"> <!-- href 属性を生成。以下はその値。 -->
      • <xsl:value-of select="($htnURI)" /> <!-- select 属性値は指定した変数 ( <xsl:variable name="htnURI"> の内容) を代入。 -->
      • <xsl:apply-templates /> <!-- htn 要素の内容、この例では htn へのテンプレートなので、その内容である klezer が入る。(アレ? これはヘンかも) -->
      • <xsl:text>/</xsl:text> <!-- htnURI + klezer だけでははてなの仕様上不十分な URI なので、 / を追加。 -->
      </xsl:attribute> <!-- 最終的な <!-- href 属性値は上で代入された変数プラス htn 要素の中身、つまり http://d.hatena.ne.jp/klezer/ となる。 -->
    • <xsl:text>id:</xsl:text> <!-- 続いて内容。 a 要素の内容にはてなっぽく id: を追加。-->
    • <xsl:apply-templates /> <!-- 同じく内容。htn 要素の内容、つまり klezer (しつこい) 。 -->
  • </xsl:element> <!-- 最終的な a 要素の内容は id:klezer となり、 a 要素は <a href="http://d.hatena.ne.jp/klezer/">id:klezer</a> となる。 -->
  </xsl:template>

最終的に出力される HTML 構文

• <a href="http://d.hatena.ne.jp/klezer/">id:klezer</a>

今回は xsl:variable で複雑なことをするわけではなかったので、 select 属性を使って値を示そう思った (つまり、 <xsl:variable name="htnURI" select="http://d.hatena.ne.jp/" /> としたかった) のですが、URI で頻出する : や / などが値へ入っているとエラーとなってしまい、うまくいきませんでした。

そもそもの問題として、変数として定義した URI が果たして変数であるのか、ということもあります。勉強不足でうまく説明は出来ないのですが、わざわざと変数として定義せずとも <xsl:value-of select="($htnURI)" /> ここを単純に <xsl:text>http://d.hatena.ne.jp/</xsl:text> としても同様の結果が得られるわけです (あくまでも変換の結果ですが) 。もう少し複雑な処理を重ねるとそれぞれの用途が見えてくるのですが。

アレ? これはヘンかもと感じた個所も確かにヘンかもなのです。単純に要素の中身を挿入したいのならば、 <xsl:value-of select="." /> あるいは、 <xsl:value-of select="self::node()" /> と指定しても同様の結果が得られる。先述と同様に (どちらが意味として正しいのかは感得しかねるのですが) あくまでも結果はということでしすし、また、こちらも同様に複雑な処理を重ねるとそれぞれの違いや用途が見えてくるのでありますが。要するに、結果に着目してしまっているので意味までは吟味していないのが現状です。やっていることは「太字にしたいから <b> タグを使う」とかと同レベル。

最後の最後でこうぶっちゃけるのはアレなのですが、根本的な問題として variable 要素と param 要素の違いが僕にはイマイチわかっていません。変数とパラメタということくらいしか (それだけか……) 。そんなわけでして少し調べてみたところ、 Variable and Parameters にて少々説明されていたのですが、それでもやはりというかなんというかわかりませんでした。ちなみに内容は以下。

[element] xsl:param

パラメタを定義します。変数との区別はわかっているだけで以下のとおりです（これ以外にありましたら、教えてください）。

• xsl:param はデフォルト値しか持てない（そのわりには同じパラメタの値を変更することができたりする）
• xsl:param は xsl:template の中で最初にこなくてはいけない（そのわりには最初にこなくても正しく処理してくれます）
• xsl:variable は xsl:with-param で値をテンプレートに渡すことができない

あとは xsl:variable と同じです。これなら一本化してもいいんじゃないかとも思えます。

<!-- カテゴリ: top-level-element -->
<xsl:param
  name = (名前)
  select = (式)>
  <!-- 内容: template -->
</xsl:param>

name 属性は必須です。

なるほど何度読み返してもよくわからない。説明が悪いという意味ではないです、念のため。じゃあなんで variable を使ったの? と言われれば、たのしいXML: XMLをIEで表示(基礎編) xsl:variableで似たような例が示されていたからです。そんなわけではっきりとわからないのも気持ちが悪いので、XSL Transformations (XSLT) 勧告の翻訳であるXSL 変換 (XSLT)をあたってみることにしました。

変数とは、ある値にバインドすることのできる名前である。変数のバインド先の値 (変数の値) は、式が返すことのできる型であれば、どの型のオブジェクトでもよい。変数のバインドに使用できるエレメントには、xsl:variable と xsl:param の２つがある。xsl:param 変数に指定される値は、バインディングのデフォルト値に限るという点が両者の違いである。内部に xsl:param エレメントが現れるテンプレートまたはスタイルシートを呼び出すと、デフォルト値の代わりに使用するパラメータを渡すこともできる。

xsl:variable と xsl:param のどちらも、name アトリビュートは必須である。このアトリビュートは変数の名前を指定する。 name アトリビュートの値は QName であり、この値は [2.4 修飾名] で解説しているように展開される。

これらの変数バインドエレメント (Variable-binding element) を使用する場合、あるバインディングを参照できるスタイルシートツリーの範囲は限定される。この範囲内では、変数バインドエレメント自身から参照可能な変数のバインディングはすべて隠蔽される。そのため、もっとも内側にある変数のバインディングのみが参照可能である。ある式のスコープに含まれる変数のバインディングの集合は、スタイルシートにその式が現れる時点で参照可能なバインディングである。

例によって例の如く意味が以下略という感じです。その他にも少し気になったところがあったので、横道にそれた個人的なメモとして引いておきます。

注: 位置によってノードを選択するために変数を使用する場合、以下のように記述しないように注意する。

<xsl:variable name="n">2</xsl:variable>
...
<xsl:value-of select="item[$n]"/>

この記述では、最初の item エレメントの値を出力することになる。これは、変数 n が数値ではなく、結果ツリーフラグメントにバインドされるためである。その代わりに、以下のように記述するとよい。

<xsl:variable name="n" select="2"/>
...
<xsl:value-of select="item[$n]"/>

または

<xsl:variable name="n">2</xsl:variable>
...
<xsl:value-of select="item[position()=$n]"/>

さらに混迷を極めたのは言うまでもなく。

長くなったので最後に。なんで「番外編」などを作ってしまったのか正直自分でもよくわかりません。適当です、たぶん。というかよくわからないことだらけならば、勉強してから書こうよ自分という感じもします。もしわからないことがありましたらご自身で調べてください。残念ながら僕は力にはなれません。ちなみに仕様の邦訳は前述のもの以外に XSLT 1.0 もあるようです。どちらがより好ましいものなのかはわかりません。

修正するのが面倒というか上手いこと説明できないっぽいので追記として

そういえば <xsl:copy-of select="self::node()" /> でも同じ結果になるのでは? などと思い、とかいろいろと試していたら何となく感じがつかめてきました。上手いこと説明できるほど理解が出来ているわけでもないので、メモとして。というか、今きちんと理解するのは面倒なので後回し。記事がしりつぼみなのはご愛敬。疲れた。あらゆる意味で無理。

変数とパラメタについては以下の文書でも言及がありました。

• Studying XML for beginners
  • Studying XSLT -- for advanced use -- [ 変数とパラメータ (1) ]
  • Studying XSLT -- for advanced use -- [ 変数とパラメータ (2) ]
  • Studying XSLT -- for advanced use -- [ 変数とパラメータ (3) ]

シリーズ! XML + XSLT 化までの道のり #4

記述年月日

2004年04月23日

単なる修正記事なので目新しいことは書いていません。修正というより……んー? まあいいか。個人的なバックアップも兼ねています。相変わらず理屈という理屈はくっ付いてこないのですが、現在の知識で清書するならばという感じで。加えて言うと、この清書が果たして理にかなっているものなのかは微妙なところ。関数の学習の逃避のついででございます。の。の。の。

シリーズ! XML + XSLT 化までの道のり #2で書いた date という名前付きテンプレートの清書

• <xsl:template name="date">
  • <xsl:element name="dl">
    • <xsl:attribute name="class">
      • <xsl:text>date</xsl:text>
      </xsl:attribute>
    • <xsl:element name="dt">
      • <xsl:text>記述年月日</xsl:text>
      </xsl:element>
    • <xsl:element name="dd">
      • <xsl:value-of select="//@YYYY" /><xsl:text>年</xsl:text>
      • <xsl:value-of select="//@MM" /><xsl:text>月</xsl:text>
      • <xsl:value-of select="@DD" /><xsl:text>日</xsl:text>
      </xsl:element>
    </xsl:element>
  </xsl:template>

清書と称するのはいくらか語弊があるので補足をしておくと、現状の HTML 文書では記述年月日を記した dl 要素に date という class が添えられている (というか自分で添えてる) のでそちらの方もついでに書き足してみました。

シリーズ! XML + XSLT 化までの道のり #3で書いた sect 要素のテンプレートの清書

• <xsl:template match="sect">
  • <xsl:element name="div">
    • <xsl:attribute name="class">
      • <xsl:text>section</xsl:text>
      </xsl:attribute>
    • <xsl:attribute name="id">
      • <xsl:text>d</xsl:text>
      • <xsl:value-of select="@DD" />
      • <xsl:text>n</xsl:text>
      • <xsl:number format="01" />
      </xsl:attribute>
    • <xsl:call-template name="date" />
    • <xsl:apply-templates />
    </xsl:element>
  </xsl:template>

こちらについても少々補足をすると、相変わらずこのまま変換をしてしまうと、全ての sect 要素に番号を振られてしまう。やりたかったとこととしては、同一の DD 属性値を持つものに 01 から順に番号を添え、 DD 属性値が変化したらまた 01 に戻り……というものなのですが、その方法がわからないのでありました。ということなのでアレなままであります。

ものすごく逃避したくなってきた

記述年月日

2004年04月23日

僕のいうことを信じないでください。

僕は嘘つきです。