孤雲野鶴

画像は、以前「最強の椅子」として紹介したサイドチェアーである。落胆、反発の数々は甘んじて受ける。しかし、この椅子は、歴史が作り上げたスタンダードだということは間違いない。

長い間にわたり、無名の工人達が、限られた工具で、試行錯誤の上に編み出した工法と構造。この椅子は何も語ろうとはしない、大仰ではなく、いつも謙虚に置かれている。しかし、そこには形を構成している驚嘆すべき工法がある（詳しくは、このブログのカテゴリー「ファニチャー」の中の、「最強の椅子」「スラットバックチェアー」で述べた）。

伝統的なスラットバックチェアーは生木から作られるが、画像のものは、生木から作ったものではない。座面はアメリカ産天然シーグラスを用いてウィービングしたもの。

初めて座ると、窮屈だと感じるのは間違いない。しかし、耐久性を考えた末に決定された奥行きである。伝統的なサイズを大きく変えたくはない。使っている間に慣れ、こういうものだと思ってくる。
そして、この椅子は実に軽い。これは最大のメリットである。

最近は、イタリアの家具が大うけで、その傾向はもうかなり長い間続いている。コンテンポラリーでモダンな雰囲気はイタリアの得意とする所かもしれないし、軽佻な現代日本建築には、うまく適合するように映る。軽佻をそれなりにモダンに見せるには都合がいい。
建築家の一部は、日本の建築の混沌状況が良いのだ、と言ってはばからないから言葉を失う。

そのイタリアの椅子の原点というべきが、実はこのスラットバックチェアーである。中世から存在し、世界で最も数多く作られた椅子である。テンポラリー（temporary）やコンテンポラリー（contemporary）ではなく永遠のスタンダード。

いずれ、「スラットバックチェアー普及プロジェクト」でも立ち上げたら良いかとも思う。無論、自作の薦めである。

ブログなどの制作で使われているマークアップ言語の一つである、XHTMLに至る今日までの過程を簡単に振り返ってみた。

XMLだのXHTMLだの、何がどうして、どこが問題なのか。ホームページやブログといわれるウェブサイト制作とはどう関わって来たのか、不明な点が多い。自分自身の理解のために調べてみた（間違っている場合、ご指摘頂けたら幸いです）。

結論（私の理解）として、文書や、様々な情報を特定のアプリケーションに頼ることなく、安全、長期に渡り、誰もが利用しやすく、カスタマイズしやすい、標準的な文法を作る努力がなされてきた（今だ進行形）。それが、SGML、HTML、XML、XHTMLなどの言語を生み出してきたといえる。

1986年ISO（国際標準化機構：International Organization for Standardization）は、SGML（標準汎用マークアップ言語：Standard Generalized Markup Language）という標準言語を規格化した。

それまでのMarkup Languageによる、共通マークアップ（マーク付）（注１）は、特定の処理システムに依存していない利点を持ってはいるが、文書（内容）とレイアウトなどの表示方法が混在し、論理的な構造を持ったデータとして記述されていなかったために混乱が生じていた。

この問題を解決するためには、文書構造の記述を、印刷や表示などの処理系から切り離し、独立した言語として定義する必要があった。このような状況で、論理構造を対象とし、処理系非依存の共通マークアップを行う文書記述言語として誕生したのがSGMLであった。

SGMLでは、文書情報を正確に伝えること、正確に保存すること、印刷や表示などの処理には関与しないことが特徴としてあげられる。さらにSGMLは、タグや属性情報などの記述方法を規定しているだけで、名前や属性を固定的に決めているわけではなく、使用者が定義（注２）すれば自由に設定できた。また、固有ソフトに依存しないテキスト形式で記述するため、保存した文書を長期間使用できるもので、まさしく汎用ツールとしての明確な理念を持った言語として構築されたのである。

そして1990年、主に電子データ交換のため、SGMLをベースにして、Web用としてHTML（Hyper Text Markup Language）が開発された。
HTMLはインターネット上での情報共有が目的であったため、DTDを自由に定義できないように固定し、記述を簡便にした。

HTMLは、「文書の構造化」という目的よりも、ページのレイアウトや装飾も含めた記述言語として使用されることが日常化し、IEやNNなどの各ブラウザも競って固有の拡張タグを採用した。また、文法的に厳格ではなかったために、多少のミスがあっても見栄えのいい情報ページ（ウェブサイト）を公開することができた。そのために、いわゆるインターネットを爆発的に普及させる要因となった。
しかしながら、本来の勧告から外れ、混乱を招いている状況から、HTMLを本来の目的である文書構造の記述言語に戻し、デザインやレイアウトは「スタイルシート」という別の文法に担わせようという方向で確認されていった。

また、HTMLの手軽さは、ユーザーがタグを設定できない、情報の意味を記述できないなどの問題があった。また、HTML文書を保存してもブラウザで見ることしかできないというデメリットがあり、Web上でSGMLを利用しようとしても様々な問題があった。
さらに、SGMLはその記法の自由度の高さから実装が煩雑で、実装・運用にコストがかかるという難点を抱えていた。そこで、SGMLをもっとスリム化し、データ交換を重視した共通マーク付けへの拡張したものとし、インターネット上の利用を前提にして思想で再構築されたものが、1998年2月10日、XML1.0（拡張可能マークアップ言語：Extensible Markup Language）として、W3C（World Wide Web Consortium）から勧告されたのである。

XMLはSGMLのサブセット（部分集合）であり（XML文書はSGML文書でありえる）、目標は以下である（抜粋）。
・インターネット上でそのまま利用可能。
・広範多様なアプリケーションをサポートする。
・SGMLと互換的であること。
・XML文書の記述の容易さ。

XMLは、その性質上、他のマークアップ言語の骨組みとして使用される位置にあり、XMLベースのマークアップ言語としては、リモート経由で他のコンピュータのサービスを呼び出すSOAPや、Web上で画像表現のためのSVGがあり、HTMLをXMLの仕様で再定義したものがXHTML（Extensible Hyper Text Markup Language）である。
XHTMLは、HTMLのタグ構造よりも厳格に定義する。そのため、形式的に扱うことが容易であり、ホームページの自動生成などは行い易くなる。

参考までに、大蔵省の財務報告書申請・公開，特許庁の特許申請など、政府機関の各省庁や、民間の電子文書化ではSGML/XMLが利用されてきている。

注１：文章中に「タグ」という先頭と終了を示す「マーク付け」を行い、それに挟まれた文章に属性を与えたり、修飾したりすること。例：<p class="date">2006年06月21日</p>など。

注２：DTD（Document Type Definition）と呼ばれ、「見出し」や「脚注」などといった要素は、SGMLの場合、記述する人が自由に定義できた。

参照資料
各種W3C勧告文書・日本語版（どら猫本舗）
SGML/XMLによる電子文書処理（日本印刷技術協会）
ＷＷＷ講座総目次（杉浦のホームページにようこそ）
PDF資料（日本土木工業協会）

ジーコは日本選手のプロ意識の低さを嘆き、中田もその点で苛立っていた。中村は、もっと多くの選手が海外での経験を積む必要があるといった遠まわしの表現でそれを指摘した（そう私は思っている）。

今回のワールドカップでも、ゴール前での弱気なパス回しと、アタックへの強い気持ちが感じられないのは、古く、城、岡野の時代から変わっていないことを再認識した。

昔、ラサール石井が指摘したように（彼が過した鹿児島での生活から感じたこと）、九州は、母系社会でマザコン男が実に多い。
今住んでいる地域でも、同様である。全国大会へ出場する生徒はいたせりつくせり、負けると、父兄のバックアップが悪いということになる。自然、子供も自立心が萎えてくる。
この風潮が、今回でも肝心な場面で人任せにするシーンを見るに付け、オーバーラップしてきた。

後がない状況で、うずくまらないで風上に向かうのは勇気がいるし、小さな成功体験の積み上げが必要なのだ。村社会リーグから出て行ける可能性を持つ選手は出て行って欲しい。どの地域でもいいと思う。個々がきちんと立ち向かう経験ができればいい。

「選手過信したジーコ監督　自主性尊重、時期尚早」（2006年06月23日22時18分）という記事をasahi.comで見た。以下抜粋。

「サッカーの歴史は、組織を超えた個人の力が最後は勝負を決めてきた」というのが、ジーコの持論だった。指示されるのではなく選手自らが状況判断を下す自主性を求めた。

日本選手のレベルは高いのか。今回のＷ杯で、世界との個人能力の差が露呈した。結論からいうと、ジーコ監督のやり方は時期尚早だった。

日本はこれまで、個人能力の劣勢を、組織力でカバーしようとしてきた。現実的な策ではあったが、個人能力の不足と正面から向き合わない逃げでもあった。

練習でシュートをはずして笑うＦＷ。勝つしかないのに、失敗を恐れ冒険的なプレーに出る勇気がない選手。日本サッカーを変えられるチームと信じていただけに寂しいと、ジーコは明かした。チームは個人能力だけでなく、プロ意識も足りなかった。

懸念されるのは、この４年間が否定されてしまうことだ。組織と個人能力は対立軸ではなく、両方備えてこそ、強いチームになる。個人重視はだめだと、組織頼みに戻すようでは、日本サッカーは退行する。

前回、XHTML1.1での記述について書き、その中でＩＥの問題点に触れた。

ブラウザによって見え方が違う、レイアウトが一様ではないという問題があり、その多くはＩＥのバグによる原因から、主にＩＥで発生しているということは、多くの方が指摘している。
その一つについて、「CSSによる段組（マルチカラム）レイアウト講座」に述べてあったので紹介したい（文章も一部、引用させて頂きました）。

前回書いた記述の順序・・
XHTMLで書かれる内容の最初の１行目には、XML宣言文が来なければならない。

２行目には、XHTMLを示す、DOCTYPE宣言がくる（例はXHTML1.0）。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

所が、比較的新しいブラウザには「DOCTYPEスイッチ」という機能があり、DOCTYPE宣言の有無や、書き方によって表示モードを切り替える。
これは、CSSを正しく解釈できるブラウザにも、アバウトな解釈をする古いブラウザに合わせた表示をさせることができるというものである。

普通に規則にのっとり、DOCTYPE宣言した文章であれば、Standardsモードになる。つまり、仕様どおりに書かれたものをそのまま解釈する。

DOCTYPE宣言のない文書等はQuirksモードとなり、アバウトな解釈に合わせる。ただし、この場合、仕様どおりに書かれたCSSが、制作者の意図どおりに機能しない場合がある。

繰り返すが、XHTMLでは冒頭にXML宣言を記述するようになっている。しかし、WinIE6ではDOCTYPE宣言より前に何か文字列があると、Quirksモードになってしまう。これでは正しく表示されない。
特にボックスモデルでは、解釈が違うため、表示が崩れる。

この対策として、古いHTMLで記述するか、先頭にあるXML宣言を書かないということも考えられるが、それはできない。
そうなると、Quirksモードになっても表示が崩れないようなCSSを書く他ない。

ここではTipを書くつもりはないが、参考までにボックスモデルバグの対処法を同サイトから引用する。
widthを指定した要素には左右のpaddingとborderは指定しない。同様に、heightを指定した要素には上下のpaddingとborderは指定しない。
paddingまたはborderを指定した要素にはwidthやheightを指定しない。
この方法なら、StandardsモードとQuirksモードの違いによるボックスのサイズに違いは生じない。

結局、シェア9割前後（？）を占めるＩＥいやＩＥファミリーで正しく表示されれば他のブラウザがどうあれ、意に返す必要はないし、Ｗ３Ｃの勧告も大した問題ではないのだ。

昔、ＩＥしか知らなかった時代、私の記述はいい加減だったから、ＩＥにはよく馴染んだ。Ｗ３Ｃの勧告に近づけるようになってからも、まだネットスケープの表示がおかしいななどと、ＩＥ側から見た評価をしていた。
今は、普通のことが普通でない状況に驚いている。

恥ずかしい話だが、今頃になって、サイトデザインについて、実に様々な問題があることが分ってきた。自分自身への理解を含め、その一部を述べてみたい。

ウェブサイトをデザイン（制作）する場合、文法にのっとって記述する。そして、それがどの程度正しいかチェックするサイトがある。

Ｗ３Ｃは書式の標準化を目指す非営利団体で、これまでにもいくつかの標準書式を勧告してきた。それが、HTML4.01やXHTML1.0などである。
その、Ｗ３Ｃも記述のチェックサービスを行なっている一つで、承認されると認証マークを貼り付けることが許される。日本で有名な検証サービスサイトでは、「Another HTML-lint gateway」（以下:lint）がある。

だから、チェックで合格することは励みになるし、記述の理解を高めることになる。

今回、サイトの記述のリデザインを行なうにあたり、どうせなら、最新バージョンのXHTML1.1にのっとろうとした。
所が、世の中の大半の方が使っているマイクロソフト社のインターネットエキスプローラー（通称ＩＥ）という、ブラウザの仕様は、勧告された記述ではうまく動作しないし、ＩＥに合わせると承認を得る事ができないということが分った。

例えば、XHTML1.1で書かれる内容の最初の１行目には、XML宣言文が来なければならない。
<?xml version="1.0" encoding="Shift_JIS"?>

続いて２行目には、XHTMLを示す、DOCTYPE宣言がくる。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

先頭の!DOCTYPEとは、ドキュメントタイプ（Document Type）のことで、DTDとは、文書型の宣言（Document Type Declaration）をしている。

問題は<head>の中に記述する以下の行。
<meta http-equiv="content-type" 
content="application/xhtml+xml; charset=shift_jis" />

これを、「lint」でチェックすると、「XHTML1.1では<?meta http-equiv>を記述すべきではありません」というエラーメッセージをもらう。

対策として、.htaccess（注１）を使って直接メディアタイプを指定するという方法がある（つまり、「meta http-equiv」の記述を省く手法）。
.htaccessの内容を「AddType "application/xhtml+xml; charset=shift_jis" .html」と記述し（注２）、サーバーにアップする。

「lint」では見事に合格するが、ＩＥは、XHTML文書として扱わずにダウンロードファイルとなる。
結局、「AddType "text/html; charset=shift_jis" .html」でなければ、ＩＥでは見られないということになり、取りも直さずXHTMLの推薦値ではなくなるため、「lint」では合格しない。

こんなことにエネルギーを費やしている事が、実にバカバカしくなってきた。ＩＥ対策を施してXHTML1.1の認証を受けることへの興味を失った。
大きなシェアをしめるＩＥを考慮すると、個人的には（自分の能力も含め）、XHTML1.0 strictで記述するのが妥当ではないかと思っている。

注１：設定、テキストファイル。自分のサーバーのディレクトリーにアップして使用する。Webサーバの動作をディレクトリ単位で設定するためのファイル。このファイルを設置したディレクトリ以下、全てのページに有効となる。

注２：XHTML1.1文書のMIMEタイプの指定は「application/xhtml+xml」が推薦（Should）。「application/xml,text/xml」が可能（May）であり、「text/html」は禁止（Must not）ではないが、非推薦（Should not）となっている。

黒豆ジュースが血圧を下げ、血流をよくする。という番組を以前、NHKで視た。ネットで調べると、NHK出版からは、「ＮＨＫ生活ほっとモーニング 黒豆健康活用術・血圧を下げて血管をしなやかに！」（ISBNコード：4-14-187631-3）という本まで出ていた。
定期検査で血圧の上がったのが分った連れ合いは、減塩に走り、水を飲み、そして、やめていた黒豆健康ジュースを再び飲み始めた。黒豆の煮汁を飲むのである。ただし、煮出した後の黒豆は、様々な料理に入っている。

そして・・
最近では、それに加えて、ウコンパウダーを溶かしたジュースである。御存知のように肝臓にいいといわれるウコン。肝機能強化クルクミンを含有し、医師も肝硬変患者に処方する。
ウコンは暑い地方の特産であり、ここサワナケートの朝市でも、ウコンやウコンパウダーを買う事ができる。

連れ合いにとって、ウコンはアルコール摂取のための予防薬という位置付けであり、元を正すつもりはまったくない（余談だが、のんべえだった私の親父は肝臓の薬を焼酎で飲み、「よう効く」といっていた）。

ワインにはポリフェノールが多く含まれるのは聞いていたから、ウコンを取りながらワインも飲む。尿酸値を上げるプリン体が多いと聞いた後はビールとワインを減らし、ほとんど含まれていない焼酎がメニューに加わった。先ずビール、次いでポリフェノールワインを少々、そして仕上げに焼酎代わりのラム酒（BACARDI Superior：日本円で約￥1200）である。

ポリフェノールの摂取はワインだけではもの足りないと思ったのか、次いで、血液の循環をよくするというココア摂取が開始された。本人曰く、便通には即効だという。

試しにネットでココアを調べてみた。

１．豊富なポリフェノールとその効能
痩身効果。特に夕食後に飲めば、食事で取った脂肪を効率的に燃やす。
活性酸素が体内の細胞などを傷つけることを防ぐ「抗酸化作用」。
末端部の血液循環を改善し、血液をサラサラにする。

２．遊離不飽和脂肪酸とその効能
ピロリ菌などの胃粘膜への、接着抑制効果。
ピロリ菌をココアを加えた培地で培養したところ、普段飲む濃度（3.5％）のココアを加えただけでも、培養開始から1時間後には菌の数は6割程度に減少し、1日経つと検出できない数にまで減少したという。

３．豊富な食物繊維とその効能
ココアの粉末の約3分の1から4分の1を食物繊維が占める。便通には効果的。

健康食品関連のサイトの常で、紹介している食品の効能は凄くて何か胡散臭い。しかし、ココアが魅力的に思えてきた。

極最近、偶然見かけた、ヤフーの社会ニュース（6月9日(金)15時29分）で、ニンジン煮れば→ベータカロチン摂取「生」の１．６倍という記事があった（伊藤園中央研究所などの研究）。

茹でたニンジンを基に作った野菜果汁を飲んで、肌の状態を調べた別の実験では、摂取後８週間で、１３人の対象者全員のシミの面積が減少することが確認されたというのである（読売新聞から）。

その日の夕食には、茹でて軽く炒めたニンジンが皿の回りに、きちんと並べられていた。

付録：機能性食品もいいが、運動が健康にいいことはわかっている。だから、毎日の夕刻には、３０、４０分走る。走るのはかったるいが、私は、ビールが旨いので付き合っている。

画像は全ラオス技術訓練短大展に出品したウィンザータイプのサイドチェアー。
几帳面な性格のスタッフが制作したもので、結構丁寧な作りで期待がもてる。このようなウィンザータイプの椅子をこの国で見ることがないせいか評判は上々。余計な過飾やデザイン処理は必要ない。改めてこのタイプの椅子のスタンダード性を思う。

参考図面を提示し、各自、多少のアレンジを許した。多少のアレンジでも、寸法出しから、治具なども変わってくるから制作と指導は面倒にはなるが、同じ物を作るよりもヤル気は出ると考えた。

実は、この椅子の制作にかかった時間より、作るための準備に費やした時間のほうがはるかに長い。
木工旋盤を整備し、古い木工旋盤の使えないドライブセンターを作り直すための加工屋を探し、出来てはきたものの不具合を直し、新しいライブセンター（既製品）を探し、座ぐり（座面加工）の工具を揃え、チセル（旋盤加工用刃物）研磨のためのグラインダーを整備しなければならなかった。

一脚位はサンプルとして残したい気持ちもあったが、テーブルセットとして教育省No.2が買ってくれたために、我々は喜んで即納した。

現在、再び同じタイプの椅子の制作を計画している。設計から作り方の定着を目指しているためである。
問題は、現地スタッフにとって、図面から、脚やスピンドル（背もたれの縦の部材）の実長を得る方法の理解が難しいことである。これをきちんと理解させなければこのタイプ椅子は作れないが、これが私と私のラオス語にとってかなりの難題なのである。

痔の手術をして以来、大便の後は水で洗わないと気持ちが悪い。
そこで、ウォッシュレット等で有名な、水で局部を洗浄する便座は実に都合が良いということになる。

東陶では、便座開発中に、何ミリグラム残るか調べたという数値を聞いた事がある。仮に０．２グラムでも都会の雑踏、千人いれば２００gの飛散。これは恐ろしいことだなあ。などとくだらないことを考えたものだった。

以前住んだマレーシアや、ここラオスではそのような機能便座はほとんどないが、有り難いことに、ピストル型の洗浄器（洗浄ガン）が備え付けられているから、それを使う。実に都合がいいのだが、時々、もの凄い高圧水が出てきて飛び上がりそうになる。
（田舎では桶に水を汲んで用意してあるが、幸い現在まで、それで洗った事はない）

成田や羽田エアポートにはまだなくて困るが（知らないだけ？）、最近は、公共施設でも洗浄器付き便座が設置されている所が多くなって助かる。

所で、古い我家は「和式汲み取り」だから、洗浄と、左膝の按配が良くなくて立ち上がるのが大変という問題で、便所の改善は差し迫った懸案事項なのである。
そこで、洗浄便座を取り付けるか、あるいは、簡易水洗式トイレには洗浄用のガンが付随しているので、それを取り付ければ安く済むと考えたりしている。しかし、冬場はマイナス１５度位に下がるので凍結の問題もあるし、便槽の溜りも早いかなあと思っている。

朝、こざっぱりした後には、ふと我家の「和式汲み取り」の問題が頭をよぎる。

現在、Ｗ３ＣのＸＨＴＭＬ１．０という文法にのっとってサイト（ホームページ）を書き直している。
以前からＸＨＴＭＬ１．０で書いており、検証の結果、承認を得たこともある。その後、サイトの作成と文法チェックはエディターの機能を使っているせいもあって割りと安心していた。
しかし、閲覧してくださる方を考慮したとはいえない部分も多々あり、エディターでのチェックは最低限のもので、利用を考慮したとはいえないものだった。

訪問者の意志を尊重するサイト作りの一例を挙げる。
私は老眼鏡を離せなくなっているが、意匠優先で文字の小さなサイトは多く、うっかり持ち合わせていない場合、読むのに往生する。ブラウザの機能で大きくさせればいいのだが、絶対単位を用いて設計してあると、文字は固定されていて動かない。かく言う私のサイトも然りだ。

ブラウザに左右されず、閲覧者に優しい、訪問者の方々の意志を尊重するサイト作りの大切さを感じ、サイトを運営する者の責任として、改善していかなければならないと改めて考えたのである。

この作業は、私には至難である。ＸＨＴＭＬの文法にしても、系統だった正しい認識を持ち合わせておらず、その場しのぎでＣＳＳ（カスケードスタイルシート：デザイン、レイアウト等を制御する命令）をいじってきたため、記述はいい加減でシンプルではない。

完全にということは難しいと思うが、今より多少は改善されたサイトを目指している。時間はかかりそうであるが・・。