#?SuikaWiki/0.9
[1]
HLink メモ
HLink [HLINK] を使ってみた。
xhtml1-hlink.xml
HLink と、その勝手な拡張を使って XHTML 1 のリンク系要素を表現してみた。
applet 要素以外を実装。
hlink-ext.dtd
HLink と、その勝手な拡張を使うための文書型定義。
+//IDN suika.fam.cx//DTD Extended HLink 20030228//EN
hlink-ext.dtd の公開識別子。
urn:x-suika-fam-cx:markup:hlink:extension
HLink の勝手な拡張部分の語彙の名前空間 URI
HLink の問題点
1. html:object/@archive や html:head/@profile 方式
(1つの属性値に複数の URI。) での一対多対応が表現できない。
(HLink WD でもこの問題は触れられており、将来の版の HLink
(が出るとしたら。) では考慮されるかもしれない。)
2. 「@」で始まる相対 URI を直接表現できない。
回避策:
・相対 URI は使わない。
・「./」を頭につける。
・「%40」に逃げる。
・そもそも「@」で資源名を始めない。
・URI との共存を諦める。
3. リンク先などが属性値以外で指定されていた場合が考慮されていない。
例:
-
http://www.example.com/
The Example Corporation
で、 item 要素がリンクの要素にすることはできない。
また、リンク先などが親要素などで指定されている場合 (input[@type='submit']
に対する form/@action など。) も使えない。 (submit の近辺は HLink WD
では未確定とされており、将来の WD が出るとすればこの問題は解決されている
かもしれない。)
4. 特定の属性値が存在する場合のみリンク、を表現できない。
(例: @type='submit' の時のみ input はリンク。)
HLink への勝手な拡張
HLink の次版が出るかは謎だし、出るとしてもそれまで指をくわえて
待つよりはと拡張してみる。 (以下、 W3C HLink 名前空間を既定とし、拡張の
名前空間接頭辞を x とする。 XSLT 名前空間接頭辞を xslt とする。)
1. hlink 要素の内容モデルを空から x の特定の要素と xslt:if, xslt:choose
に改める。 (xslt:if 要素及び xslt:when 要素の内容もこれと同じにする。)
x の特定の要素:
x:target
x:replacement
x:role
...
2. リンクかどうかの条件判断が必要な時は xslt:if または xslt:choose 及び
xslt:when を使う。 (XSLT の要素を使うのは、単に語彙を借りただけで
深い意味は無い。)
3. リンク先は次の手順で決定する。
1. xslt:* があればそれを評価する。
2. x:locators 要素があってその内容があれば、それをリンク先とする。
3. x:locators/@node 属性があれば、その node をリンク先とする。
4. hlink/@locator が @ で始まれば、その属性をリンク先とする。
5. hlink/@locator が URI なら、それをリンク先とする。
*. リンク先が node または属性の場合は当該 node を探し、
存在すればその値をリンク先とする。
以上でリンク先が決定しなければその要素はリンクではないとする。
(空文字列である URI (自分自身。) と、値が存在しない場合を区別する
必要がある。)
4. hlink/@* に対応する拡張要素が存在する時は、拡張要素を採用する。
拡張に対応しない UA との互換性のため、拡張要素による指定値を標準属性で
表現可能な時はそうしてもよい (MAY)。
x:target 要素
内容: (x:locators | x:langs | ...)+
リンク先資源について。
x:* 要素
属性:
node 値を与える node を、 XPath で表現。 (当該要素が self。)
type 値の形式。 Case sensitive。
内容: #PCDATA
直接値を与える場合は node 属性を省略し、内容にその値を入れる。
(しかしこれは hlink/@* 属性で実現可能だから、そちらを使うほうがいい。)
type 属性は既定値未定。 "space-separated" 以外の値は未定義。
「単独の値」の指定以外の場合は必ず指定するべし (SHOULD)。
独自拡張する時は名前空間接頭辞で始めるべし。
x:onSuccess, x:onFailure, x:loading 各要素
属性: node, type
内容: #PCDATA
hlink/@* 属性の対応するものと定義が異なるので注意。
代替内容などを XPath で指定する。例えば html:object なら
, html:img なら 。
x:loading はリンク先を読み込み中の場合。 html:object なら
。
文書との関連付け
HLink WD には hlink:definition 属性の方法と (HTML なら) html/head/hlink:hlink
要素 (html/head/hlink:hlinks 要素にした方が適切だと思うんだが。)
の方法が挙がっているけど、いっそスタイル・シートにしたらどうかと。
例:
利用者リンク・シート
HLink をリンクの表現に関するスタイル・シートとみなせば、当然利用者スタイル・
シートを用意してみたくなる。例えば、標準の HTML UA では blockquote/@cite
は onRequestSecondary だけど、よく使うのに面倒だから onRequest にしたいとか、
iframe 要素が embed なのは癪だから replace にしちゃえ、とか。
画像表示を最初からはしないとか、新窓で開くのを抑制とかの既存の UA
の機能も再現できそうな予感。
# そうなると継承問題があるから、
# のようなものが必要かも。
実装
完全実装は面倒そうだけど、簡単なものだけならこんな感じで実装できそう。
@namespace html 'http://www.w3.org/1999/xhtml';
html|style[type="application/x-hlink+xml"] hlink {
-moz-binding: url(hlink.xbl#hlink);
}
hlink.xbl#hlink は、文書の onLoad の時にでも、 {@namespace}:{@element}
要素を検索して、 @effect='replace' and @actuate='onRequest' なら
html:a 要素を捏造して・・・とやっていけばよさそう。
(捏造要素には適当な flag になる属性をつけておくのを忘れずに。)
hlink-test.xml
HLink を上記の方法で style 要素に使ってみた。適当にでっち上げた fooml
で書いてある。
hlink-xbl.xml
XBL による簡単な HLink の実装。非常に基本的な機能しか実装していないし、
style 要素の方法しか対応していない。 (実用的には style 要素ではなく
外部ファイルにする必要があるから、まだ使えないだろう。)
html:style/hlinks/hlink にこの XBL を binding すると、この XBL はその hlink
要素の情報を元に当該文書の要素をリンク化する。 html:a 要素的なリンクは
内部的に XLink の属性を与え、 hlink/@effect='embed' なリンクには内部的に
html:object 要素を挿入する。
理論上は xlink:* や html:object を直接使わずに、当該要素に更に XBL binding
を与えることが出来るはずで、そうすればリンクの種類ごとに別の xbl:binding
要素で処理することが出来て、 XBL code がきれいになって表現の幅も広がる
(かもしれない) のだが、 document.addBinding () で Mozilla が落ちてしまう
ので使えない。 (XBL の中で XBL を呼ぶから?)
hlink-script.js
HLink 文書を html:link[@rel='stylesheet'] を使って外部スタイル・シート
として利用するための外部スクリプト。
test.xml
linkizeHTML(document)
World Wide Web Consortium
test-hlink1.xml
test-hlink2.xml
未解決の問題点:
1. html:script 要素がないといけない。
2. html:link 要素が無いといけない。 xml-stylesheet 処理命令に対応するには
擬似属性を解析する必要がある。 (処理命令の書式も標準化して、 DOM
で簡単に扱えるようになっていれば良かったのに。)
3. 代替スタイル・シートに未対応。 Mozilla は text/css など対応しているもの
以外のスタイル・シートを document.styleSheet やメニューの選択肢に
入れてくれないし、 onStyleSetChanged のような event もない。
代替スタイルを認識すること自体は簡単に可能だから、 html:select
要素を使って文書内で切り替えるような方法で個別に実装することは可能だろう
(但し既に与えたリンク属性を一旦破棄する処理が必要になる)。
Moz に手を入れずに汎用的な形で実装するのは骨が折れそうだ。
4. HLink stylesheet の媒体型は application/xml (または text/xml)
でないといけない。 Mozilla が XML として認識してくれない場合は動作せず、
保存しますか?と聞かれたりする。 (外部文書の DOM 木を得るために html:object
要素を使っている。他にもっと良い方法は無いか?)
5. HLink stylesheet が異なるホストにある場合、 Mozilla の安全上の制限から
使用できない。 (html:object 要素の中の DOM 木を取得できない。)
*. xbl:script 要素は実装されていないようだ。 (XBL 内で html:script 要素を
使った場合も効果なし。) hlink-xbl.xml と hlink-script.js は大部分の code
が一致するので統合したいんだけど。
HLink definition for RFC 2629
#
mailto:
urn:ietf:rfc:
urn:ietf:std:
注: 属性値が URI でないリンク要素がある。このため x:locator 要素を拡張し、
内容に xslt:value-of 要素を入れてみた。
この機能により (実装は更に複雑になるが) 様々な形態のマーク付けを処理
出来る。 XPath や XSLT の関数が使えるから、属性値から特定の文字 (SP とか)
を除去したりも出来よう。 uri:escape() という関数を用意しておくとして、
次の文書片から辞書へのリンクを実現できたら素敵だ。
XML 文書片
- リンク
HLink 文書片
http://dict.example/ja?
しかしここまで来るともう最初から XSLT でやってしまえという気もしなくはない。
HLink が Link recognition for the *XHTML Family* である以上、
こんなに拡張してしまってはいけないのかもしれない。
hlink-xbl.xml 改訂版
hlink-script.js で XBL 化できなかったのは html:script のせいだが、
あえて外部スクリプトにする必要はない。スクリプトは XBL に埋め込んでしまえば
いいのだ。
test.xml 改訂版
World Wide Web Consortium
実際に使うときは html:style の内容を外部スタイル・シートとして xml-stylesheet
処理命令で XML 文書と関連付ければよい。
上例では html|link:first-child に bind しているが、これは実際どの要素でもいい。
(実際にやっていることは HTML Transitional で言うところの html:body/@onload
の指定だから。) 但し foo:root 要素に指定したらなぜか何も表示されなくなるとか
相性?があるみたいだから、表示上特別な意味を持つ要素は避けた方がよさげ。
文書に必ず1度だけ登場する要素型があれば最適だ。
(なお、複数条件に該当する要素があれば複数回処理が行われる。
あまり影響はない (ようになっているはずだ) が、あまり良いことでもない。
なんなら実行チェックを入れて1度しか実行されないようにしても良いだろう。)
かくして上述の問題点1は解決した。
Magic attribute
hlink 要素の多くの属性は、実際の値又は属性値参照の2種類の値をとり得る。
これに違和感を感じる人は多い。 [HLINKWG]
拡張可能な値の指定
http://foo.example/bar
@mediaType
embed
replace
ID & IDREF
XML で規定されているリンクが ID と IDREF だ。 W3C HLink
ではこのいずれも表すことは出来ない。
@attrName
XML の規定にこだわることはない。こんなのもありか。
childElement/text()
でもこれと同じことだ。
#{x:uriEscape(@attrName)}
#{x:uriEscape(childElement/text())}
但し x:uriEscape() は適当に URI escape する関数。
新窓で開く
target=_blank を嫌う声は多い。一方で支持する声も多い。 XLink や HLink
でもそういうものがあるし、 XHTML 2.0 でも XFrames の関係で復活するだろう。
新窓で開くのを支持する最大の理由は、著者の想定する文書の流れが乱れることだ。
それならそんなところにリンクをはらなければ良いと思うのだが、
気持ちは分からなくもない。
そんな場合でも、著者の想定する流れのリンクなら、もちろん新窓は開かない。
つまり、著者は2種類の性質のリンクを想定しているのだ。
target=_blank
を嫌う声は多い。一方で支持する声も多い。
XLink や
HLink
でもそういうものがあるし、 XHTML 2.0 でも XFrames
の関係で復活するだろう。
この例に、次のような著者スタイル・シート (の断片) を適用すれば、
著者の要求は満たされるはずだ。
new
_self
そして、この挙動を嫌う利用者は次のようなスタイル・シート(片)を適用しておけばいい。
_self
TO DO
・XML1 + HLink + XSLT -> XML2 + XLink
・role/reverseRole と profile URIs
まとめ
・HLink WD 仕様ではまだ表現できないリンクがある。
・HLink をスタイル・シートとして扱ってはどうか。
・XML 及び DOM を実装した UA では、 UA そのものに手を加えなくてもある程度まで
なら文書側で HLink を使用できる。
・調子に載って拡張すると限定版 XSLT になる危険性がある(w
参考文献
[HLINK] 『HLink: Link recognition for the XHTML Family』
[HLINKWG] HTML Working Group Voyager Issue Tracking System - HLink
[XBL]
[XHTML]
[XLINK]
[XPATH]
[XSLT]