XMLの最近のブログ記事
xsl:sortでソートする対象をPHPで切り替えるという処理です。
ちょっとつまずいたのがxsl:sortに渡すselectの値。
ここはxsl:for-eachの文脈の中で処理されるらしく、単純にxsl:variableで変数を切り替えても処理されないっぽい。
なので仕方なく、XSLT側もPHPに変えて、XMLにリクエストされたGETの値でXSLTにリクエストされるGETの値を切り替えて、その値に応じてxsl:sortに渡すselectの値を切り替えるようにしたらうまくいった。
とりあえず、他に処理がうまくいかない理由が思いつかないのでたぶんそういうことだと思う。
PHPの習作にとつくってみてる。
あれね、結構楽しいけど、うまくいかないとこが多い。
とりあえずイメージビュワーっぽいのと、テキストエディタっぽいのができた。
まあ、ぼちぼちつくっていこうかと。
ちなみにFirefoxでしか動きません。
長いので別ファイルにまとめました。
しかしやっぱりプレーンなHTMLが一番美しいです。なんでみんなわかんないんだろう?
なんか今日3時間ぐらい考えてた。
xsl:for-eachで決まった数のブロック毎に親ノードを追加する方法。
帰りに自転車こいでる時にふとおもいついて帰って書いてみたらうまくいったので覚え書き。
<xsl:for-each select="./section/box[position() mod 2 = 1]">
<xsl:variable name="p"><xsl:value-of select="position()"/></xsl:variable>
<xsl:element name="img">
<xsl:attribute name="src">
<xsl:value-of select="./image" />
</xsl:attribute>
</xsl:element>
<xsl:element name="img">
<xsl:attribute name="src">
<xsl:value-of select="../box[position()=$p+$p]/image" />
</xsl:attribute>
</xsl:element>
</xsl:for-each>
ループする毎に加算される値はないものかと、いろいろ調べてたんだけど、たしかにposition自体が加算されるのは自明の理。けっこう入門書に書いてあるような代入なのに、いやーまったく気づかなかった。
すごく単純で柔軟性のない構造の定義です。
見た目はなにも変わらないうえ、特に役に立たないので自己満足ですが、とりあえず復習。
- 複合型の宣言
- <ELEMENT ノード名A (ノード名Aに内包されるノード1,ノード名Aに内包されるノード2)>
- 単純型の宣言
- <!ELEMENT ノード名A (#PCDATA)>
- #PCDATAは文字列を含む。#PCDATAにした要素は子ノードを持てない。
- 属性の定義
- <!ATTLIST ノード名 属性名 CDATA #REQUIRED(必須) or #IMPLIED(省略可能)>
とりあえずおもしろいんでいいです。
読んだ本をXMLでまとめてXSLTでスタイリングしてみるの巻
DTD関連リンク
まあ、そんなわけでXMLスキーマとか書いてみたりしてます。
とりあえずDTDから書いてみようかと思ったら、なんか検証するツールが必要なので、探してみました。
その名もValidator。まんまですね。はいそのままです。 Mac OS X 、Windows 、Linux and Similar Operating Systemsで、うごくそうです。
もちろん英語です。でもなんとなく理解できます。
あと、昨日扇風機を出しました。うちはエアコンがないので暑いです。毎年買おうかと思うのですが、あまりエアコンに頼りすぎると、汗腺がうまく機能しなくなるという噂を聞いているので、もう10年くらいがんばっています。
でも暑いです。さすがに今年こそ買おうかと思います。
でもきっと買いません。
耐えられなくなったら、他人の家に転がり込むか、どこかの店にでも行けばいいのです。
でも他人に迷惑をかけてばかりいられないので、夏はどっかの店でよくコーヒーを飲んでいます。
暑いからです。
でもスターバックスはたばこが吸えないので嫌いです。
そんなに暑いのなら、こんな世界は燃え尽きてしまえばいい。
暑いからです。
誰かぼくにエアコンを買ってください。
汗をかくのは嫌いです。早く秋になればいいのに!
暑いからです。
入門XML
なんかちょこっとAjaxとかやってみて、なんとなく知った気になっているXML、でもAjaxなんかXMLの用途のほんの一部でしかないので、じゃあXMLって何? って聞かれたところで、情報構造を記述するマークアップ言語なんていうありきたりの答えしかだせないんじゃあ、これは宝のもちぐされなんじゃないか。
情報にはそもそも構造なんてなく、構造化し、検索、再利用を容易にするためのツールキットとしてのXML。
HTMLは構造化言語というよりは、表示するための言語、表示するための骨格を記述する言語なので、けっこういろいろキツイ、やっぱXMLで構造化し、それにHTMLで骨格をつくり,CSSでビジュアライズする、といった方が、よりWebを豊なリソースとして扱えるようになる。
ちなみに本の表紙は卵の殻のついたヒヨコでした。そうね、まだ殻のついたヒヨッコです。
最近オライリー本けっこう読んでますが、Web情報アーキテクチャ
まあこのレベルの知識は今後必須かと。
この記事は2008年5月現在の状況に基づき書いています。その後検索エンジンの状況が変わることがありますのでご注意ください。
そんなわけでXSLTでHTMLにTransformationしたファイルがどんな感じで検索エンジンに認識されるかとかいうはなし。
まずSEO的には、まあふつうにXHTMLでセマンティックマークアップしたほうがよいのではないかという結論。
見出しのマークアップとかをきちんとしたほうがよさげ。
ちなみにXSLTのほうは検索エンジンは無視するようで、純粋にXMLとしてキャッシュされてました。
じゃあ逆にそこでスパムめいたSEOとかも可能になるのでは、とか思た。つまりXSLTでユーザーには表示させたい情報だけみせて、ロボットにはキーワード満載のXMLファイルを読ませる。すると、上位表示? されるのかもしらん。
別にXMLファイルが上位表示されにくいようになっているわけでもないようだし、ただどうも最近の検索エンジンは文脈まで読めるようになってるとかなってないとかなので、度が過ぎると逆に順位が落ちる恐れもある気がする。
というか、もう既にスパム行為によるSEO対策なんて時代錯誤もいいところで、そんな事をやってる業者もまだあるらしいけど、そのうちそんなヤクザな会社は潰れます。
ただ、今回やってみたXMLファイルは全くの独自仕様のものだったのでRDFとかにした場合はまた違うのかもしらん。あるいはRDFで記述してXSLTした場合とかには案外上位表示されたりして。
XHTML+CSSも検索エンジン主導、というか上位表示のために普及した感じは否めないので、RDF+XSLT+CSSの普及も検索エンジンが効果を明言したら広まるのかもしらん。
XMLを利用しているひととかも、XMLがただAjaxとかFlashとかで情報を分離するためのフォーマットくらいにしか思ってないひとが多いらしい。
ぼくもなんだかんだで漠然とした概念しかないので、間違えてる部分もあると思うけど、これからもずっとWebでくってこうと思ってるひとには必須の知識なので、わかる範囲でご紹介できればと。
セマンティックWebとは、なんかWebのデータをコンピュータが理解可能なフレームワークにあてはめて、ほいでもって組織だとかの枠を超えてデータをみんなの共通の資産にしよう、とかいう感じのものらしい。
これが実現すればA社とB社が合併した時とかにも情報資産の統一とかがすごい楽に行えたりとか、あるいは今腐る程ある電子マネーの一元化とかの時にもスムーズな移行が行えたり、便利極まりないことになるっぽい。
ちなみにセマンティックWebでビジネスモデルを構築している会社もあるらしいので、すでに夢物語ではなくなっているっぽい。
で、そのベースとなるのがXMLとその周辺技術になるらしい。
XMLベースのRDFで情報の文脈を記述し、そいつの意味情報をWOLで定義する。意味情報を追加されたRDFはそれをもとに再定義が可能なので、構造的に異なるRDFでもWOLをもとに再定義を行えば、共通のデータフォーマットとして使用できるようになるらしい。
じゃあ、全部のデータをRDFで記述しないといけないのかというとそうじゃなくて、XMLで記述すればそれで問題ないっぽい。たとえばXHTML、これはもうXMLなので、GRDDLというXMLからXSLTを使ってRDFを抽出する言語を使用してXHTMLからRDFを抽出すれば、無問題。
ちなみこれで検索精度も上がるらしい。SPARQLというRDFに検索をかける言語があって、よくわからんがなんかすごいらしい。
まあ、あれですよ。ぼくらがやってるコーディングとかもこういった将来のことを見越して、ちゃんとValidで構造的なマークアップを行っていかないと、そもそもXHTMLで記述する意味なんてなくなってしまうかもしれないわけじゃないですかね。
Web のクリティカルな部分はこういった情報を資産として扱って、人間の知識の蓄積と知性の発達に寄与するというところにあると思うので、なんかそのへんをたくさんのひとにわかって欲しい。
Webデザインではなくて“インターフェース設計”ってちゃんと呼称を定めるとかも。だってWebデザインって呼んじゃったら、全ての行程が“Webデザイン”ですからねぇ。
もはや(X)XHTML CSSではないのですが、まあなんか便利かな、と思って。まあweb標準が盛り上がってXHTMLが普及したっぽく、じゃあ次はXMLへ移行ということで、覚えておかないと後々困るだろうからとか思って。
とりあえず基本的なものを載せてます。あとはおいおい勉強しつつ追加していきたいと思っています。
ちなみに今後の予定としては、
のリファレンスとかも追加していこうと思っています。
いつになるかは未定ですが。
構成や仕様の変更による資料の整合性を保つと意味で、やっぱXMLって便利です。
見せるために分けてますが、実際は一枚のXMLファイルで管理しようというはなしです。
あれね。ボタンできりかえれるようにしてネットワーク上で閲覧できるようにすれば、情報共有も進むし。
とりあえず思いつく限り書いてみた。そういえば今年は小説は1、2册しか読んでない。
最近やっとXSLTなんぞを勉強し始めました。
情報構造と装飾を完全に分離するという意味では、なんとも不完全さを感じる(X)HTMLですが、やっぱXMLとXSLTでやるとこれは美しいものができあがりそうな気配です。
スタイルのためにどうしても構造がくずれてしまう(X)HTMLに比べ、構造化するためにあるXMLは、コード自体が凄くキレイ。スタイルをかける場合にもXSLTで(X)HTMLに書き出してからのスタイリングになるので、情報構造自体は別のファイルで分離される。
後方互換とかアクセシビリティとかの面では実際どうなのかとかもあるけど、まあその前に最低限のレベルで使えるようになるのが先かなと。
これでやっとまともなコーディングができるようになれるような気がするので、ちょっとドキドキ。
しかしコーディングするにしても、他人のデザインはその設計思想が理解できない。そもそもビジュアルのことはよくわからんのだけど、先に構造化した情報を基にビジュアライズをしていくというのがどうにも正しいWebアーキテクチャらしい。でも、構造化前提でのライティングなしには構造的なWebページというのはできなかったりするので、なにはともあれ上流行程でのインフォメーションアーキテクチャをしっかりと行わなければ、マークアップだけではどうにも限界がある。ディレクターよりも業界で足りないインフォメーションアーキテクトを、どうやって確保していくのかがクオリティの高いWebサイトを構築する上でのカギで、アーキテクチャありきのユーザビリティエンジニアリングとビジュアライズができれば、すくなともインターフェースでは最強クラスになれると思う。