勝手にしやがれ - 2004年5月 -

目次

人様のものは勉強になる

2004-05-02

何処かのXSLTファイルを覗きていたら(URIは忘れてしまった)、こんな感じの記述を見つけた。

【XML】
<?xml version="1.0" encoding="UTF-8"?>
<root attr1="value1" attr2="value2"/>

【XSLT】
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/root">
    <output attr="{@attr1}-{@attr2}-value3"/>
  </xsl:template>
</xsl:stylesheet>

【出力XML】
<?xml version="1.0" encoding="UTF-8"?>
<output attr="value1-value2-value3"/>

属性値テンプレートは知っていましたが、こんな使い方も出来るなんて初めて知りました。何個も含められるし、文字列も同時に扱っていいんだ。ちなみに僕はずっと、こう書いていました。

(xsl:template のみ)
<xsl:template match="/root">
  <output>
    <xsl:attribute name="attr">
      <xsl:value-of select="concat(@attr1,'-',@attr2,'-value3')"/>
    </xsl:attribute>
  </output>
</xsl:template>

ものを知らんで何かをやろうとすれば、手間が掛かります。XSLTは自由度が高いから、”知っている”と”知らない”とでは大きな差が出る。今回だって知り得なかったら、永遠と上のようなまどろこしい記述をしていた事でしょう。

人様のものを見るという事は、それが良いものであれ悪いものであれ、勉強になる。そりゃ、良いものの方がタメになるが、悪いものでもそれはそれでタメになる。だから、見る機会が増えるという事はそれだけ勉強できる機会が増えるという事だ。

と、言う事で、僕の使っているXSLT群も公開しときます。以前からバックアップ用としてWeb上に置いてはあったんですが、リンクする事も無くひっそりと置いてあったんで、これを機にリンクしときます。但し、僕個人が使う為のものだから汎用性には乏しいし、コメントを入れるという習慣が僕には無いので把握するのが難しいと思います。ついでにZippoの方も置いておきます。まあ、今回の属性値テンプレートの事も知らなかった素人ですので、内容が乏しいと思いますが、その辺はよしなに。

バグをもってバグを制す

2004-05-04

相変わらずブラウザ毎の挙動の違いには骨が折れる。俺はただ英数字にOptimaフォントが使いたいだけなのだ。

font-family:"Optima","Hiragino Kaku Gothic Pro","ヒラギノ角ゴ Pro W3",sans-serif;と普通に指定してやると、Safariのバグで、font-weight:bold;と指定しているにも関わらず日本語にboldがかからない。色々とフォントを指定したり並び替えたりと試してみたが、駄目。ヒラギノ角ゴの英数字はあまり好きじゃないので、仕方なくOptimaの代わりにLucida Grandeフォントを最初に指定した。これだと日本語にもboldがかかるようにはなるが、なにか腑に落ちないので、例の如くネットで対策探し。

で、結局、CSSバグリスト@CSSバグ辞典スレッドの『未知の擬似要素/クラスを指定したセレクタは不正』を採用し、gecko系だけでもOptimaフォントで表示できるように、以下のようにした。

body{
  font-family: "Optima","Trebuchet MS","Lucida Grande","MS Pゴシック","ヒラギノ角ゴ Pro W3",sans-serif;
}

/* for nonGecko */
body:nonGecko,body{
  font-family: "Lucida Grande","Hiragino Kaku Gothic Pro","MS Pゴシック",sans-serif;
}

ついでにMacIEでの、overflow:auto;を指定した要素の内容が消えるという致命的なバグに対応する為、『スタイルシート内でバックスラッシュの直後にある文字が無視される』を使って、バグをもってバグを制した。その他、WinIE対策もして、ママ納得いく表示が出来たしだいである。

しかし、いつまで続くのだろう、この不毛な戦いは....

マイクロソフトに問いたい

2004-05-07

曉に死すの北村さんが纏められている『IEは窓から投げ捨てられるべきか』を読んで思った事。

天下のマイクロソフトは、一体いつまで、現状の古いブラウザを供給し続けるのか?

「シェアは保ちたい。だが、新しい技術は導入しないし、独自路線を突っ走る」のでは、WWWを使う皆が不幸になる。

セキュリティホール

2004-05-22

Macも決して安全では無いと言う事か。この記事にある実験サイトにアクセスしてみたら、ヘルプとターミナルが勝手に立ち上がった。技術的な事はよく分からんが、確かに”ホーム”のフォルダくらいは削除できそうだ。アップルの速い対応を望む。

ソフトウェア・アップデートにて、”Security Update 2004-05-24”が公開されてました。早速当ててみたら、ヘルプビューアは依然勝手に起動するも、ターミナルは起動しなくなった。

DTD取得回避できた

2004-05-28

XHTMLをパースする際にDTDを取得しに行かれて時間が掛かるのが嫌なので、XHTMLを扱う時はxsltprocのオプションを使ってDTD取得及び検証を回避していた。でも、それだとHTML固有の実体参照が使えないし、何よりxsltprocのインデント出力が気に入らなくて、「何とか他のプロセッサでもDTD取得を回避できんかな」と日頃から思っていたところに、北村さんのXSLTでcatalog_fileを使う - 徒委記を読む。「これを参考にすれば行けるんでないの!?」と早速準備してみた。

xhtml11-flat.dtdやらcatalogやらCatalogManager.propertiesやらは、取りあえず/Library/DTDsというフォルダを作ってその中に、resolver-1.0.jarはXalan-Javaが入っている/Library/Java/Xalan/binの中にぶち込んで、下記の様にしてみた。

【ディレクトリのイメージ】
root ─ Library ┬ Java ┬ Extensions ─ Saxon関係のjarファイル
               │      │
               │      └ Xalan ─ bin ─ resolver-1.0.jar
               │
               └ DTDs ┬ xhtml11-flat.dtd
                      ├ catalog
                      └ CatalogManager.properties

最初は各種ファイルを丸写しにやってみたが、まるで駄目。で、色々と試行錯誤を繰り返し、以下の様に各種ファイルを設定する事でDTD取得回避に成功した。

【catalog】
<?xml version="1.0" encoding="UTF-8"?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
	<public publicId="-//W3C//DTD XHTML 1.1//EN" uri="file:///Library/DTDs/xhtml11-flat.dtd"/>
</catalog>

【CatalogManager.properties】
catalogs=catalog.xml;/Library/DTDs/catalog
relative-catalogs=false
static-catalog=yes
catalog-class-name=org.apache.xml.resolver.Resolver
verbosity=1

【saxonで動かす為のシェルスクリプト】
#! /bin/bash
CLASSPATH=${CLASSPATH}:/Library/Java/Xalan/bin/resolver-1.0.jar:/Library/DTDs
export CLASSPATH
java net.sf.saxon.Transform -x org.apache.xml.resolver.tools.ResolvingXMLReader -y org.apache.xml.resolver.tools.ResolvingXMLReader -r org.apache.xml.resolver.tools.CatalogResolver $* 
# end.

お陰でずいぶんと速くなりました。これでXHTML化の際には、思う存分saxonが使えます。とは言うもの所詮JAVA。やはりxsltprocには敵わない訳で、こちらの方もネット越しDTD取得の回避策を施し、一件落着。

...と、思ったら、思わぬ事態が発生。DTD検証したものを出力すると、<head profile="">とか<a href="URI" shape="rect">とか出力されるし、あげくの果てに<pre xml:space="preserve">と出されます。よ〜くDTDを見ると、それらは何れも固定値で、パースする際に勝手に補完される模様。XMLパーサー的に正常な動作らしいし、DTD的に言っても間違った記述じゃないんだが、どうにも腑に落ちない。他の人のサイトを見てもそんな記述は皆無だし、そもそも固定値だったら無くてもよいだろうと言う事で、xhtml11-flat.dtdを少し改変して出力されないようにして、なんとか使える様になったのである。