業務にて整形済み XML 文書を C# の DOM で操作中。xml:id が欲しい。
11月27日の昼休み、大変久しぶりに物欲の神様が降臨なさいまして、CLIE を賜りました、俺の金で。と言う訳で (どう言う訳で?) 2台目の CLIE、PEG-TJ25で御座います。
前回購入した際 (2000年10月21日のろばQ日記)の評価は2万円分の価値はある
、Sony のジョグダイヤルは Palm 本来の持ち方を完全に否定している
だったのですが、PEG-TJ25は店頭価格が18300円 (ヨドバシカメラ上野店、2003年11月27日現在) で、ジョグダイアルの位置も Palm のボタンと並んで配置されており いてぃーず じゃすと つぅ まぃ りくえすとで宜しいか(英語が)? 私の要望にぴったりなのです (うわぁ……日本語で言い直してる……)。
とりあえず、色々弄って遊んでいるのですが流石に比較対照が3年も前の製品 (PEG-S500C) だけあって (ハード、ソフト共に) インタフェースが洗練され、また、非常に小洒落た感じ (3年経って洗練されていない訳が無いのでこれは寧ろ開発者に失礼か?)。ツールとしての評価はまだ出来ない (買ったばかりであまり叩いていない) のですが、デグマ手書き入力の認識能力などは非常に優秀。今の所ろばQは Graffiti2 を使っているのですが、ローマ字入力から漢字変換するよりDecuma入力で最初から漢字入力したほうが最終的には早いかも知れません (かな入力の漢字変換も可能)。
あと、燃える漢のデジタルガジェットとしてコンパクトキィボードPEGA-KB100も購入。
(製品の都合上) ストロークが目茶目茶浅いのですがキィの間隔はそれなりにあり、薄型ノートパソコンのキィボード程度にはガシガシ打てます。ただ、重心が Plam 側にあるので、キィボードが暴れやすく、また Plamも外れ易い (端子を守る為にわざと外れやすいのだと思いますが) のが難点か。
Another HTML-lint のメーリングリスト、渡辺さんの投稿 [htmllint 1142] ID & NAMEを契機に識者の間で騒がれております HTML 4.01 の ID 属性の大文字、小文字問題 (勿論ろばQも知りませんでした)。
一口に言っちゃいますと、HTML 4.01 では ID 属性値は全て大文字として解釈される、と言う事 (記述は可能だが、解釈は大文字)。つまり、id="a" を持つ要素には識別子 A でアクセスせねばならないし (aではアクセス出来ない)、id="a" name="a"と言う表記はid="A" name="a"と処理され文法違反になる、と言う事。
で、ろばQ屋本舗の対応ですが……何もしません。例えば HTML 4.01 文書の id="a" に対する hyper link の URL として #a なんて表記をしておりますが (全部書を精査した訳ではないが多分1箇所以上ある) この場合、相手先 HTML 文書において name="a" 不在の為 (多分) 不適切なアクセスと言う事になってしまいますが、この段階で即文法違反ではない事、とりあえず文書単位での URL 引渡しは問題ない事、そして相手側メディアを確認しつつの全文書精査の (ろばQ側) 労力に対して効果が小さい事 (意訳: 致命的文法違反じゃないし、面倒臭いし) が主たる理由です。
とりあえず、今回の教訓は皆、XML 文書に移行しようと言う事で (違う)。
やりたい事は沢山有るのですが、些細な事に時間をとられ、積もり積もって何も出来ないでいます (つまり、時間の使い方が下手。ろばQと同じ位時間を労働に費やしていて、且つ自分の趣味を両立させている人は沢山いると思います)。
と言う訳で1週間ほど3時間睡眠で生活してみたのですが、(起きてはいられるのですが) 慢性的に寝不足で全般的に意欲も減衰。どうやら副交感神経やらなんやらに多大な負荷が掛かる様なので中止。現在5時間睡眠に再度変更。
予め計画を立てる事、計画通りに実行する事、物事に優先順位をつける事が大変苦手なので (これは ADHDの典型的な症状ではあるまいか……、今までそう診断された事は無いのですが) Palm の力など借りて色々無駄を省いていく所存。
最近思いっきり太っているので (最大で体重69Kg、体脂肪24%)、減量中。目標を体重を58Kg、体脂肪率を20%未満として、現在66.5Kg、体脂肪率22%。リバウンドに戦々恐々しつつとりあえず順調に推移中。
減量法は毎日体重を量って、グラフにすると言うもの (それにより減量への意識が強まり間食などを思いとどまるのだそうで)。元々ろばQは昼食や菓子の類は平日日中には一切食べて居らず、殆どジュースで太っていたのですがこのダイエットを始めてから殆どお茶と水に切り替え。
あと、頻尿気味なので、とりあえずコーヒを絶ってカフェインの摂取量を減らしてみたら (お茶を飲んでいるのでカフェインは摂取している)、回復の兆しが。これにより喉の渇きも減少して飲む水の量も減少中。
とりあえず部屋を片付けれ > 俺。
イラクは現在危険な国であって、武装警官や軍隊の護衛なしにはアメリカやアメリカに協力的な国家の国民が活動するのは難しい。と言う事ははっきり解ってたわけですが、それがこの上なく悪い方向で実証されました。
イラクは安全だから自衛隊を送っても大丈夫で、テロの対象となり邦人に死者が出ても屈してはならない? 政治的都合で憲法第九条と日米同盟の両立という図るから無理が出る、そしてその無理なしわ寄せの結果として起こるべくして起こった事件、ろばQにはそう思える。
政府はイラクが危険地帯である事を認め、そこに自衛隊を送るなら憲法を変更すべきである。もし、それが無理だ、国民を説得出来ない、と言うなら米国政府に自衛隊派遣という出来もしない約束をした事を謝罪し、戦争状態にあるイラクで現行憲法内で最善の対応をせねばならない。
疾うの昔に転換点は過ぎている。今すぐ日本の国際社会における軍事的貢献のあり方に関して速やかに論議した上で必要があれば憲法改姓の手続きを取るべきである。
風邪をひきました。
まぁ、色々あって今年は低め。単純に結果出せてないので、当然であって不満無し (と言うかもっと低いかと思っていた)。
それより何より、何だかんだいって控除で13万弱持っていかれたのが吃驚ですよ。ここから年金問題やら失業保険問題やらで誰でも言えそうな公憤を書き散らして返せこの野郎みたいな展開になっても面白くないので、ちょっと人とは違う事を書いてみましょうか。
賞与の一部が親会社の株で支給されました。
失業保険は返って来るかも……。
賞与も出たことなので、netlaputaに振込みを行い12月17日から1年契約をしてきました。これで2004年12月16日までは http://www.netlaputa.ne.jp/~robaq は保持されます (多分)。
超遅レスシリーズ。
自分の著作物はblockquote要素或いはq要素に成り得るのか (解決編) のおまけに関してdivを嫌ふ理由、そしてISO-HTMLを今までで一番熱く語る (釣瓶雜記)でご返答を頂いておりました。ろばQは当初単純な、言葉尻の話として捕らえて、文字通りおまけとして書いたのですが、かなり奥が深い様子。
端的に言えば文書構造を markup する言語仕様で、仕様にない要素を markup する時どのように対処すべきか (ただし、その仕様にはどれにも属さない汎用要素は存在する)と言う問題。
ろばQはこのような場合どのようにmarkupが解釈されるかを基準に考えています。
例えばしいて言えば見出しだが、既存の h1-6要素では決してありえない要素があったとします。この場合ろばQは見出し一覧を作成する DOM 処理や XSL 変換で処理対象に成るべきかを考え、見出し一覧に含まれて然るべきであるならば h1-6 を用い、そうでなければdivを用います。勿論、一見見出しのようだが実は段落ならば p、実は作者への連絡方法ならaddressを用います (参考: HTML 4.01 の h6 より下のレベルの見出し)。逆に見出しとも解釈出来そうだが見出しとして処理されてはならない場合、ろばQは何らかの回避策なしには h1-6は用いないようにしています。
さて、ここで話の発端となった blockquote や q の代わりに div や span を用いるとした記述を自己引用してみます (覚えた言葉を早速使ってみる。……子供か! 俺は)。
自分の著作物を引用出来ない場合はblockquoteやqは間違いになるのに対し、仮に出来たとしても自分の著作物なら転載も可能なのだから、確信が持てない場合はとりあえず
class="reproduce"とでもしておくのが安全かとは思うものの (以下略)
さて、ここでろばQは何を安全
と言っているかというと、blockquoteやqは間違いであるにも関わらず、引用として解釈、処理される危険性に対して、自分の著作物なら転載も可能なのだから
blockquoteやqを用いないことが安全
と言っている訳です。つまり、属性要素を乱用すると本来HTMLが持っている語彙が損なわれる事と、同種の、しかし、逆方向の懸念として既存の属性要素を拡大解釈し過ぎると本来HTMLが持っている語彙が損なわれると言う事があり、ろばQはこの件に関しては後者の懸念をより重視した、と言う訳です (尤も、自分の著作物を引用出来ない場合
の話だという前提は既に破棄されていますが)。
まづマークアップありきではなくて、まづテキストありき
と言う言葉は大変もっともだと思います。目的が文書の公開であるなら所詮 HTML は単なる手段、或いは器の類であって、拘る対象ではないと思います。しかし、最後にmarkup後の文書になりきのですから、人に先だって UA が処理することを念頭に、UA に伝えたいことを出来るだけ詳細にmarkupするべきだ、ともろばQは思う訳です。
既存の要素と言い切れない要素をどのようにmarkpuupするかの続き。内容的に異なるので別ける。
ろばQは ISO-HTML やそれを用いた文書の markup を不完全だ、不足だ、とは思っておりません。ISO-HTML の階層構造の表現方法や、その他はその仕様において完結していると思います。しかし、ろばQは UA に対して文書の更なる処理を望む為、更なる処理のためのmarkupを行うべく XHTML 1.1 を使い、段落ごとに div 要素でグループ化したり、あるいは、class を設定しています。
恐らく最も ISO-HTML 利用者とろばQとの違うところは、ろばQはmarkup済みの文書を人間が読むものとは見なしておらず、機械が人間向け文書を生成する為の種と見なしていると言う事です。これは HTML (Media Type: text/html) と XHTML (Media Type: application/html+xml) の違いといってもいいかも知れません。
ろばQにとってmarkup済み文書は自然に人間が (あたかも原稿用紙に文章を書き込むように) 文章を書く過程でそのままmarkupされ完成するものではなく、初めに人間が書いた文章を一旦加工して生成される物であり、たとえばソースの人間にとっての可読性はメンテナンス性の向上以上の意味を持っていません (ここら辺は先日のre: XHTML 2.0 の私案……見出しとセクションにも通じるものがあります)。
じゃあ何で RDFXML に移行して HTML は XSL 変換で出力される結果にしてしまわないかと言いますと、そこまで手が回らないじゃコラー、(ろばQのこの種の技術の習熟速度が遅すぎて) 時間に関する費用対効果が望めないんじゃコラー。
ろばQは人物が小さいのでご家庭にある普通の棚にも簡単に収納が可能です。
風邪が治りました。
12日の日記にmarkupをmarkpuとtypoしておりまして訂正。
まぁ、単にそれだけなのですが、(ろばQの認識順で) まずそふぃあさんに指摘して頂ききましてその後2chでまで晒されまして、ま、ただのtypoだしね～とか独り言を言いつつ顔を真っ赤にして grep tool を起動した次第でございます。何はともあれご指摘ありがとうございます。
また、そふぃあさんからtypoご指摘の際というよりも、そのtypoが拡散している点が気になる。どんなテキスト処理をしているのでしょう
と言う言葉を頂きましたが、今回の場合は1回のtypoがcopyされた物です。まぁ、ろばQをリアルで知っている人には有名なのですが、ろばQが単語の n 文字目と n+1 文字目を逆転させて記述したり、発音したりと言う事はよくある事なので、最終的にどういう処理系が何故こんなtypoを起こしたか、と言えば最終的には脳の問題です。有り体に言えば馬鹿だからと言う事で。
ちなみに、今回の誤字脱字は読めば解る範囲でよかったのですが、時々私は何々が好きでは有りませんと書こうとして私は何々が好きすと書いたり、これはAではありませんBですと書こうとして A、B を逆に書いてしまったりする事があります。この場合この誤りを指摘出来るのはこの世にろばQだけな訳で、実は更新してから気が付いて慌てて直したなんて事が1度や2度ではないので困り者です。
なお、今回の場合、ヘルプにもまた、誰の目にも明らかな誤字、脱字などの修正に関しては修正履歴を残さすずに (ins、del 要素を用いず) に修正する場合があります
と予め書いてありましたので、何食わぬ顔で (ins/del要素を使わず) 修正しちゃおうかと思ったのですが、じゃすてぃす2さんから最初、markpu って単語がほんとにあるのかと……
とのお言葉を頂きまして、もう、どうしてくれようかコンチクショウ。
と言うか、upする前に一回読み直せ > 拙者。
伊豆の土肥へ行って参りました。例年は、ノンアルコールがテーマですが今年は更に減量と言うのを加えまして、3度の食事はしましたが、途中一切の間食無し。バスの中でも買ってきた水を飲み、話しかけてくる先輩後輩を無視して本を読んでいました。そろそろ旅行そのものから爪弾きにならねぇかなぁ。(それで生きていけるなら) 出来れば村八分の引き篭もりとして生きて行きたいろばQです。
例年のバスガイドは中年の方が多いのですが、今年は (恐らく20代の) 若い方。はっきり言って下手でした。そもそもどの道、中年だろうが、若者だろうがバスガイドさんの風景解説なんか誰も聞いていません。バスの運転手は勿論必要だし、旅行代理店の添乗員も (弊社の旅行会幹事は毎年持ち回りであり、要するに素人なので) 必要だと思いますが、バスガイドさんはどうもいらない気がします (飛行機の添乗員ほどサーヴィス良くないし)。観光バス会社の方はバスガイドの有無を選択式にして他社と価格差をつけて見ては如何でしょうか、と思ったり。
初日に何処だか水族館の様な施設に行ったのですが、海豚と海驢の曲芸をやっておりました。
笑ってしまったのが、芸の事を全部遊びと表現している所。本当に遊びなら何で芸の後に一々餌与えてるのでしょうか。イルカやアシカを調教して芸を仕込み、見世物にするのは野蛮だと言う配慮から自主的にやってますと言う態度を取りたいのでしょうが、それで海豚や海驢の立場がどう変わるのでしょうか。子供すら騙されないと思います (まぁ、人対人ならこういう見え見えの嘘も時に礼儀として必要だと思いますが)。
保護団体に対して何か効果があるとは思えませんし、子供向けならこれは海豚と海驢の仕事で、だから仕事をしたらご飯が貰えますと言った方が余程教育にも良いし、実際世の中の仕組みに則しているのでは、と思う次第。
どの道芸をする海豚や海驢には関係のない話なので、どうでもいいですが。
日曜日に久しぶりに起動しましてレベルが49になりました。限界突破の季節です (FF Ⅺ ではレベル50から51になる為に、クエストをクリアせねばならず、そのクエストが限界突破と呼ばれている)。
始めたのが2002年の07月10日。1年と6ヶ月強プレイしまして実プレイ時間が約1600時間 (67日弱)。
まぁ、パチンコみたいな物で (パチンコって1回しかやった事ありませんが) 趣味と言うより暇つぶしの類と思って頂いて結構かと思います。少なくともゲームでは既に有りません。勝ち負けもなく、だらだらとその世界が続いているだけです。
仕事の合間を縫って、年内に50に成れればいいかなぁ、程度の気分。
何故忘年会。嫌な事でも有ったのか。
一般にHTMLにおいて、全ての略語にabbr要素やtitle属性を記述すればいい物ではない、と言われております (実は具体的に言及した仕様や勧告、noteを知らず)。
しかし、XSL 変換や DOM による操作などにより文書の単位が変更される (分割されたり統合されたりする) 場合、元の文章では既に説明済みであるとしてabbr要素やtitle属性でmarkupされていない略語が単体で切り出され新しい文書に挿入される場合もあるわけで、この場合、abbrとtitleをソースに全部記述しておくか、処理過程において同文書からabbr要素やtitle属性を探索、補完させるようにするか、abbrとtitleの記述を諦めるかする必要がある。
諦めず実行する場合、処理系の負担を考えれば (ここで処理系の負担とは、UA のみならず XSL や DOM を記述する人間も含む) やはり最初のソースの全てのabbr要素とtitle属性を記述しておくのが最も楽な解決策なのではなかろうか。
勿論、処理後の文書を人間が読む時に一々abbr要素とtitle属性が記述されていると邪魔だ、と言う事であれば、それはその際 UA が人間向けの表示を変更し、自動的に過剰と判断出来る情報を隠蔽すればよいのではないかと思う。
ちなみに、間近に同一文書からの引用がありそこで出典が明示されているからといってciteが省略されたblockquote要素やq要素に関しても同じ。と言うより寧ろこちらの方が (いざ問題が起こった場合は) 問題が大きい。
一つの完結した文書から一部分だけ抜き取って評価したら、そりゃ不都合が発生する (場合がある) のは当たり前な訳で、全ての略語はすべからくabbr要素とtitle属性でmarkupされているべきだ、などと言う気は毛頭有りません。
飽くまで処理の対象となる素材としての文書の場合の話。
日曜日に年内の予定を調べましたら当日 (日曜日) しか確実に休める日がない事に気付き急遽那珂川さん、時輪さんの所へ押しかけて (突然で失礼しました) お会いしてきたのですが、そのとき有ろう事か社員旅行土産の温泉饅頭 (薄皮黒糖) を家に忘れて行ってしまいました。
で、その時には痛ませても勿体ないので自宅で食べてしまいますと言ったのですが、帰宅して調べてみると賞味期限が妙に長いので取って置くことに。
と言う訳で、年末か年始あたりにご挨拶に伺った際に2週間前に購入したあと放置されていたけど賞味期限はかなり先の温泉饅頭をお持ち致しますので内容、成分表などお気に為さらずお召しやがられて下さい。
3年も経つと、そろそろ、あ、21世紀なんだな、と言う気がしてきます。
那珂川さん大絶賛と言う事でKill Billをレイトショウで観てきました。クエンティン・タランティーノは馬ー鹿ーだーなー (誉めています)。
映画本編に先立って偉大な映画監督に捧げる。深作欣二 (1930-2003)
ってなテロップが表示されたのですが、要するにKill Billはタランティーノ監督がそれ系の撮りたいシーンを順番に並べただけの映画。
狙い過ぎたシーンが観客に格好良いと映るか、失笑を誘うかは紙一重の部分がありますが、と言う意味ではマトリックスが紙一重で格好良い方を狙っているように Kill Billはダンボール 5, 6枚の所で笑ってしまう側でしかも全部狙ってやっている所が凄い。マトリックスの 1 が B 級バカアクション映画として好きだったのに、2 作目以降ではお上品に一流映画を気取った展開しやがってこの野郎、と不満を漏らしていた人にお薦め。
いや、マトリックスもシリーズ全体通して好きですけどね。多分 DVD も買って 3 回は観るし (3 回ならレンタルで済ませろよ > 自分)。
RSS と言うものを使うと Site の要約やら更新情報を XML で配信出来ますよ、と。で、その存在は知っていたのですが、RSS は飽くまで情報であって文書ではないので所謂 browser は HTML リーダであって、RSS の解析機能を持っていないのでそのままだと browser などで閲覧する事が出来ません。で、こういう時には XSL で RSS を HTML などの文書に変換するのが一般的なので、じゃあ、RSS は XSL 覚えてからでいいやと思って早半年。半年経ったら RSS 用 UA とか browser への実装が進みまして、じゃあ、XSL 抜きに RSS をとりあえず作っちゃおうか、と言う事で、The Web KANZAKIのRSS -- サイト情報の要約と公開を読んで勉強を開始。
第一印象としては簡素で最低限の RSS を書くだけなら XHTML よりも習得は簡単そう (名前空間の接頭辞とか突っ込み始めると当然複雑になるが、それは XHTML を含めた全ての XML で同じ事)。とりあえず、応用技術、周辺技術としての RDF や Dublin Core あたりは一旦素通りしてとりあえず書いてみて年内目処でまずは公開してみよう、と思う次第 (正しくは RSS が RDF の応用技術なのですが、今回は RSS の記述が目的なので RSS の為の RDF の勉強に留める、と言う事で)。
と言う訳で、習作として (あまり習作になってませんが) ろばQ屋本舗のサイト要約とろばQ屋本舗の更新情報を書いてみました (このリソースは永続的ではなく、近い将来削除される可能性があります)。将来的にはこれを取り込んでろばQ屋本舗の内容一覧を生成出来るようになるといいのかな……。更新情報の配信開始はもう少し時間がかかりそうです (一旦始めてしまうと、気軽にやめられないのえ運用コスト削減の為のノウハウがまず欲しい)。
凝り始めるとあらゆる index や contents list の類を全部 RSS にし始めそう > 俺。
釣瓶雜記の2003年12月20日土曜日 へ)に反応。、はっきりとは書かれていませんが、多分先日のmarkupされた文書に望む物へのお返事なんだろうと勝手に解釈して反応。
なんですが、もう、ろばQとしては前回書いたこの1段落に尽きます。
ろばQは ISO-HTML やそれを用いた文書の markup を不完全だ、不足だ、とは思っておりません。ISO-HTML の階層構造の表現方法や、その他はその仕様において完結していると思います。しかし、ろばQは UA に対して文書の更なる処理を望む為、更なる処理のためのmarkupを行うべく XHTML 1.1 を使い、段落ごとに div 要素でグループ化したり、あるいは、class を設定しています。
はっきり言って本論に関するろばQの主張はこれでおしまいです。文書の形式的な構造なんぞをそんなに重視して、一體どうするのか
と仰っていますがUA に処理させますとしか言いようがありません。だって、そもそも HTML 自体が UA に処理させるための規格なんですし。
後は蛇足です。
1992年の文書。
This allows some limited trivial nesting (eg LI within UL) but no general nesting、云々とある通り、當初のHTMLはSGMLアプリケーションであるにも拘らず、基本的に入れ子を避けるべきものとして考へられてゐた。ISO-HTMLは、入れ子にされた見出しを認めない點で、この當初のHTMLの青寫眞を受繼いでゐると言へる。他方、section要素タイプを導入したXHTML 2.0のドラフトは、この青寫眞と眞向から對立するものであると言へる。
ISO-HTML が入れ子にされた見出しを認めていないのは HTML4.0 の subset として ISO-HTML であれば (DTD などISO-HTML 固有の記述を除いて) 自動的に HTML4.0 として通用するようにする為、つまりその段階で存在した技術的制約が理由であって当初 HTML に存在した制限を受け継いだ物ではない様に思われます (実際 DTD には見出し構造を入れ子で表現する為の DIV1-6 が定義されているのはご存知の通りで、少なくとも DTD の筆者は入れ子の概念が併記されている方が良いと判断した、と言えるのではないでしょうか)。
また、当初 HTML が入れ子構造を嫌った理由もMany text editing systems (Microsoft Word, The NeXT text object, the Mac text object, etc) handle text in a variety of styles but do not have any concept of nestable structure in the SGML sense.
とあるように、当時のエディタに合わせたこれまた技術的な理由であって、ろばQは今現在この技術的問題は解決したと思っています。従って、見出しを入れ子の構造で表現するの宜しくないと言うのは問題解決の手段に過ぎず、その問題も解決し、既に対立の構図は消滅したとろばQは考えます (もし当時に XHTML 2.0 相当の規格が立案されていたら、周辺技術や環境へ配慮した HTML と全く配慮しない XHTML2.0相当の規格の間で対立が発生したとは思いますが)。
俺としては、矢張りdivだのsectionだので、構造をネスティングによつて明示すべきだとはどうしても思へない。それは過剩マークアップではないか、と云ふ思ひを捨て切れないのだ。構造の明示を禁じられたISO-HTMLに則つて書かれた文書でも充分に、各々の見出しの支配範圍は人間でもコンピュータでも容易に確定し得る筈なのである。
それは過剩マークアップではないか
とありますが、過剰とは何に対して過剰なのでしょうか。ろばQは HTML を一般的なブラウザで閲覧する場合、或いは ISO-HTML として妥当性検証などの処理をする場合、確かに過剰だと思います。なんと言っても実際に ISO-HTML 文書を browser で読んだり validator で妥当性を検証する場合、それで足りているのですから、足りている所に更に付け加えれば即ち過剰です。その上でろばQが section 相当の要素を欲するのは当然ろばQの要求に足りていないからであってろばQの要求に対しては全く過剰では有りません。
では、ろばQの要求とは何か、と言えば DOM でsection 要素相当の文章単位の操作を行う時、markup されていない範囲を見出しの位置関係から特定するより、先に XHTML に見出し範囲を明示的に markup しておいた方が DOM の記述も、実際の処理時間も負担が少ないからです (実際 ISO-HTML で見出しの妥当性チェックが出来るのですら見出し範囲の markup 必須でも不可欠でも有りません。単に色々楽をする為に手を抜いている結果です)。
つまり、例えば DOM の HTML moduleに getSection とでも言うような見出しを指定すると従属範囲を Range で返却するメソッドが追加されたらろばQは section 要素相当の範囲の明示を辞めるかもしれません。もっと言えば、2001年宇宙の旅の HAL の様な人語を解する コンピュータが現れたら、ろばQは一切markupなんかしなくなるかもしれません。markup なんか、読み手のUAに伝える為に仕方なくやっているだけなんですから。
フォント弄り派と構造明示派とは、マークアップをごてごてと行ふと云ふ點においては軌を一にしてゐる
無茶な同一化を承知で言ふけれども、フォント弄り派と構造明示派とは、マークアップをごてごてと行ふと云ふ點においては軌を一にしてゐると俺は思つてゐる。
その通りだと思います。少なくともろばQは同意します。
俗に言うフォント弄り派のmarkupが何故批判の対象に成るかといえば、それが本来 em や strong で表現されるべき要素を font 要素で記述して HTML の語彙を破壊したり、或いは視覚障碍者へのユーザビリティを低下させるからであって、markup の分量が多いからでは有りません。逆に言えばろばQは HTML の語彙を守り、ユーザビリティに配慮して作られた HTML 4.01 Transitional をろばQは否定も非難も出来ません (ただ、運用が大変だし、古い思想のmarkupなのでろばQ自身はそんなmarkupしたくありませんが)。
同じように構造を明示的にmarkupした結果それによりHTML本来の語彙の意味付けが破壊されたり、ユーザビリティが破壊される場合、それは批判の対象になると思いますが、それらを含むその他の問題もないのでれば、(通信や、UAの処理に著しい負荷を与えない程度の) 過剰markup自体は批判の対象にならないとろばQは考えますし、従ってろばQは自身のmarkupを (簡素な、ISO-HTMLと比較した場合に) 過剰markupと評価されても全く問題があるとは思いません。
そもそも ISO-HTML の ISO は国際標準化機構の意味であり、規格の統一と標準化の団体です。当然 ISO の名を冠する以上は出来上がった HTML も一定水準の品質を満たし、また安定している事が求められる筈です。
そこで問題となるのは、解釈上の余地です。markup は機械的に行われたほうが要素の意味付けに関する誤謬や解釈の相違の余地がなく、品質が安定するのは言うまでもありません。
では、ISO-HTMLが要素の解釈の相違の余地をなくし、品質の安定を図っているのでしょうか、それこそが見出しの出現順序の厳格化、Strict より更に数を減らし誤解の余地を減らした要素群、完成後の文書を変更してしまう script 要素の排除 (ISO-HTML 文書を最終的にユーザに届けられる文書とするなら、最終的であるはずの文書を ISO の管理下にない (かも知れない) 外部の script によって書き換える手段を与える script は大変に都合の悪い存在といえるでしょう)、del/ins のinline限定要素化、HTMLの理念にそぐわない見栄え系要素のとstyle属性の排除、いくつかの要素の省略の禁止ではないでしょうか。これらの制約は簡素なHTMLを目指した物ではなく、品質の安定と向上をを目的としたもので、簡素な HTML は単なる手段、結果なのではないでしょうか。
ISO-HTML は文書の階層化による構造明記を嫌う、という人もいますが、本当に構造化を嫌ったのであれば何故 HTML 4.01 で認められている HTML 要素の省略が、開始、終了tagともに省略禁止と変更されているのでしょうか。HTML-HEAD-BODYの流れは殆ど自明と言えます。DTD上の解釈も、妥当性チェックも精々 BODYの開始Tagがあれば殆ど自動的に補完が可能です (少なくとも見出しの従属範囲の特定よりは格段に楽な話です)。ではなぜ ISO-HTML がHTML の開始終了tagを、HEADとBODYの終了tagの省略を禁じているか、それは品質向上の為に文書構造の明示がしたかったからに他ならないのではないでしょうか。
飽くまでろばQの考える、との但し書きが付きますが、ISO-HTML の特徴と利点は安定した品質のHTML文書の保証である、とろばQは考えます。
今年は一年が早かった……具体的には 1/1[年/年] 位。
毎年恒例の今年の総括 (と、言いつつ昨年は書いてませんが)。
とは言え、さま吉さんが癌になった事が殆ど全部と言っても良いのが今年のろばQ。この種の影響は距離が近いほど大きい訳で (多分この影響力は距離の自乗に反比例して弱まるのではないでしょうか)、ろばQにしてみれば大陸で新型肺炎が流行ろうが、スペースシャトルが墜ちようが、イラクで戦争起きようが、知人が大病を患ったほうが大事。
勿論、素人目にも日本が国連主導によらない国家単位の利益追求の結果としての戦争に参加する国になった事が、来年以降に、あるいは知人の大病よりも大きい影響を生むかも知れませんが、それはそれ、今年の総括と言うことで。
さて、それはそれとしてろばQ屋本舗読者向けに他の話題をしますと (さま吉さんを知らない人には関係ないし、さま吉さんを知っている人にはいまさらなので)、公の方でろばQ自身に大きかったのは就職してから７年経ってやっとまともな開発業務についた事 (ろばQは開発として就職しました)。まぁ、実際やってみると殊の外面白くない訳ですがまぁ、紙媒体で転送データを毎日検査するとか役人向けの、コンピュータ処理を前提としていなかった時代の書式の書類を1日中書きまくり、上司と役人の間でスタンプラリィをするとかに比べれば 100 倍は創造的です (必ずしも創造的な仕事の方が面白いとは限りませんが)。やっぱり C 系のプログラミングは面白いなぁ! (文法殆ど一緒なので別に Java でも言いですけど)
私事では、Object 指向を覚え始めて (多分、いま入り口までは辿り着けて居るのではないかと) ちょっとはマシな javascript をかけるようになった事 (3ヶ月以上前に書いた自分のコードを見ると、書いた奴を絞め殺したくなりますが)。また、RSS をやっと書き始めて HTML としてではない XML を利用し始めた事でしょうか (そろそろ application/xml の意味がある世界が見えてまいりました)。来年あたりはぜひとも XSLT を覚えてここら辺をぜひとも自動化したい所。
それでは皆様良いお年を (棒読み)。
創作物発表の場としては紙媒体で発表したい、入手したい物を除いては殆どinternetにその場を移譲することが可能となってしまった同人誌界。あとの価値は祝祭空間としてのコミックマーケットなのですが、そこにも価値を見出さない人、つまりろばQには殆ど価値が無くなってしまいまして、はっきり言って人に会って来ました。
と言う訳で1日目はKing's Courtで時輪さん始め猫公国系の方々と、3日目は娘娘飯店でありみかさとみさんにお会いしてきました。特にありみかさんには、目茶目茶忙しい時間に約束もなく長時間押しかけてご迷惑をお掛けしました (身勝手な感想を言わせて頂ければ楽しく話し出来ました。ありがとうございました)。
さぁ、来年は参加するのでしょうか。
釣瓶雜記 2003年12月27日土曜日 い) への反応。一連のシリーズの最終回 (になるでしょうか……)。
まず、私は構造の明示は絶對に必要とは言へないと言つてゐます。ろばQさんは構造の明示は絶對に必要とは言へないが、私は明示すると言つてゐます。この二つは對立しません。
と仰る通りで、後は必要ない物にどれくらい価値を見出して実際書くかどうかに関する一般論が残る訳ですが、多分これに関してもわざわざ論議する必要も無いだろう (つまり、ろばQとしては各人勝手にすればいいと言う程度、と言うことで。
ただ、この論争 (と言うより対話、と言ったほうが良いでしょうか) の切っ掛けにもなった div 要素の使いどころですが、1個所だけどうしても口煩く言いたい所が。
divやspanには、それ自體何の意味も無く、それは（ろばQさんの仰る意味での）語彙ですらないと判斷するからです。こんなに頼りない要素型を、何か有意味な要素の代りとして積極的に登用する氣にはなれません。
一般論としては全くその通りで、例えば HTML の解説本にこのように書いてあったとすればろばQは正しい記述と認識すると思います。ただ、今回、この論議においては (つまり、そもそも一見引用のようで、実は引用ではない文をmarkupする場合のdivとspanに関しては)、汎用属性 div と span は、他の、その場所に出現しうる要素ではないと言う意味を有している、つまり、div は見出し (h1-6) でも段落 (p) でも引用 (blockquote) でもない、と言う意味、span は強調 (em, strong) でも略語 (abbr, acronym) でも引用 (q) でもない、と言う意味です (当たり前ですが、それぞれの意味であれば、それぞれの要素でmarkupされている筈です)。
選擇とは他の（正しいかもしれない）選擇肢を斬捨てる事ですから、解釋＝選擇が危險なのは當り前です。他方、無意味なdivやspanを用ゐることは、實は解釋ですらありません。
従ってろばQは、(この言い回しを借りて言えば) divやspanを使うと言うことは全ての （正しいかもしれない）選択肢を斬捨てる事であり、他のあらゆる要素ではないと言う解釈だと思っております。
半ば自分宛ての文章ではないと確信しつつ (だからこそ勝手に解釈して
云々などと言う前置きをわざわざ書いた訳で) 書いた文章にまで丁寧にお付き合い頂きありがとうございました。とりあえず以上でろばQ側の主張は終了で、この上の反論などは特にありません。