順調に PR になった。あっという間に勧告になってしまいそうな勢いだが、果たしてこの 1.1 というのはどんなふうに扱われるのだろうか? …などと思っていたのだが、よく見てみると実は CR が出たのは丸一年も前の話だった(くずおれる男AA略)。
ところで、これらのドラフトのステータスをよく見ると、XML 1.1 の最新版を除いて URI の末尾にスラッシュが付いている。かつてはずーっとスラッシュ無しで、XML 1.0 や Namespace 1.0 などの古いリソースを除いてはほとんどが 301 でスラッシュ付きのアドレスに飛ばされていたわけだが、最近のリソースでは改善されつつあるのだろうか?
過去のマーク付けノートを一通り見直した。三日かかった…。
以下、記述の修正ないし補足をした記事の一覧(ただし、些細なものや時間経過による変化についてのコメントなどは挙げていない)。ていうか、基本的に記事の末尾に追記する形で修正/補足してあるので、騙されぬよう。
"EMPTY" と "(EMPTY)"まだ何か誤り (typo・ローカルなリンク切れなど含む)があったら突っ込んで下さい。
簡単→面倒な順で、やることまたはやりたいこと。
]]> の認知について調べる。(済: 2003-11-12: マーク区間終了の認知)上から順にやっていくか。
MSE の認知の方を先に片付けてしまった。元ネタはマーク区間終了 - SuikaWiki である。ここでの疑問は以下の通り。
[2] マーク区間終了の文字列は、「マーク区間宣言の外」では出現してはいけないことになっています。「外」とはどこからどこまでかはよくわかりませんが、 SGML 処理系や XML 仕様の解釈から推測すると、要素の内容と文書型宣言 (後者は元からありえない。) では駄目みたいです。属性値表記内とか、注釈内とかに書いても問題なさげです。
で、調べてみた。msc は認知様相 CON DSM 制約 MSE, mdc は認知様相 CTX MD. ここで、マーク区間終了 = msc, mdc ― (95)
であるから、MSE は CON DSM でしか認知されない。つまり、リテラルや注釈の内部に ]]> という文字列を記述したところで、]] が msc と認知されることはないから、これは MSE とは見なされない。すなわち、この文脈での文字列 ]]> は、マーク区間宣言の外側に現れたマーク区間終了は, 誤りとする
という JIS X 4151 の文言には抵触しないのである。
以下、]] が msc として認知される範囲で考える。認知様相 DSM で msc を認知するケースでは、MSE は常に正しい MSE として扱われるので、エラーの要因とはならない (DSM というのはマーク区間の内側なのだから当然)。結局、マーク区間宣言の外側に現れたマーク区間終了
というのは、「マーク区間宣言の外側の内容として現れた文字列 ]]>」に他ならないわけである。
# 冒頭の引用について振り返ると、マーク区間終了の文字列は
と解釈してしまったのが敗因(謎)と言えそうです。って何か偉そうに書いてますが、ぶっちゃけ MSE が地の文に書けないというのはこの記事を読んで初めて知ったのでした。
追加。
いやあ、 XUL や XBL は勉強する必要ないと思いますよと思った。カネにならないし、将来性無いし。
そもそもの目的が「草案/研究段階の仕様に対する実装を今簡単にかつクロスプラットフォームで実現すること」なので、その意味では将来性は必要ないと言えばなかったり。
# 僕は Mac ユーザなんで、クロスプラットフォームってのはある意味最重要。
具体的に言うと、jjc みたいに仕様と実装をセットで公開するような真似ができたらカコイイなあと。もっとも自分で仕様を書くつもりは余りないので、実際には草案用の実装を自分で用意してみたい、という程度ですが。
でも、本格的なアプリケーションを作るための勉強をするほどのバイタリティもない、というか他にもやりたいことが山ほどあるのでまだそっちを専門的にやる気になれない、ということで、XUL あたりが目的に適った手段かなーと。
# とか言いつつ、ちゃんとメリット/デメリットを理解している自信もないので、できれば引き続きぶっちゃけた突っ込みを希望。「お前はわかってない!」とか。
え? カネ? お、お金は…。ほら、セマンティックウェブはお金じゃなくてロマンだから(意味不明かつ問題発言)。
<del datetime="<<<YEAR-4>>>-<<<MONTH-2>>>-<<<DAY-2>>>T<<<TIME>>>+09:00"><<<SELECTED CARET>>></del><<<CHANGECREATOR(MSIE) SAVE BROWSE(MSIE)
CHANGECREATOR(MMKE)>>># CHANGECREATOR(MMKE) の後に SAVE がないのは、それをやると IE がファイルを読むより先にクリエータが mi に戻ったりしちゃうことがあるためです。
WFC: In DTD
の意味 - XML Core 関連を公開しました。
# 今後この手のある程度まとまった(?)文章は、極力ノートでなく独立した文書として公開することにしよう。
だってだって(半べそ)、例えば HLink を実装したいとか思ったら、まず XML ブラウザが必要になるわけで、Lisp とかで書くとしたら XML ブラウザを自分で書けとかいう話になってしまうのでは? いや、というかその辺りからして既に分かってないので、議論になんないのですが。
ぶちゃけた話、具体的に興味があるのは XML の語彙の実装オンリーなので、既存の XML ブラウザに機能を追加するようなことがしたい/できればよいのですががが(©さとみちん)。
余談だけど、Topic Maps の実例って初めて見たなあ。結構面白かった。構文は XML のを使ってたんだけど ― ていうか Topic Maps って XML 版もあるんだ (XML Topic Maps, 名前空間 "http://www.topicmaps.org/xtm/1.0")。今知った。
そこで、ISO-HTML 文書の ID 属性値には小文字を使わないことが推奨される。具体的には "ABCDEFGHIJKLMNOPQRSTUVWXYZ.-_:0123456789" の40文字だけを使うこと。
HTML 4.01 や ISO-HTML を利用している人は必読。というか、「name の併記が無く、小文字を含む id で識別される HTML 4.01 や ISO-HTML 文書の断片へのリンクを作成している人」も読む必要あります。
# 何で今頃になるまでこんなことに気付かなかったのか、というような気もするのだが、気付いた人もよく気付いたものだ。そういえば、かつて ISO-HTML ユーザガイドのソースを見たとき、id と name で大文字小文字が食い違っているのに気付いたものの「気持ち悪いけど、よく考えたら SGML 的には問題ないのか」と納得してしまっていたことを思い出した。駄目だなあ。
# しかし、既存の文書の書き換えは大変だなあ。というか、XHTML Media Types (ja) とか、HTML 版を勝手に HTML4 互換の XHTML 1.0 に書き換えているので、id の値がオリジナルと異なっちゃってるし。しかしこれ、原文は原文で HTML 版と XHTML 版で id の値が違う上、コンテントネゴシエーションを利用しているので、そのままではセクションに対するリンクの作成のしようがない。具体的な版 (.html とか .xhtml とか) に対する URI 参照にする必要が?
# ともかく、後で具体的にまとめます。というか、個人的にでもガイドラインを作らないと混乱してしゃーない。
ところで、HTML4 / ISO-HTML の SGML 宣言にこんなことが書いてあるのに気付いたのだけど。
QUANTITY SGMLREF
ATTCNT 60
ATTSPLEN 65536 -- These are the largest values --
LITLEN 65536 -- permitted in the declaration. --
NAMELEN 65536 -- Avoid fixed limits in actual --
PILEN 65536 -- implementations of user agents. --
TAGLVL 100
TAGLEN 65536
GRPGTCNT 150
GRPCNT 64
これらの HTML は Web SGML なのだから QUANTITY NONE を宣言できるわけで、These are the largest values ermitted in the declaration
というのは正しくないと思うのだけど、それはともかくその下に書いてある Avoid fixed limits in actual implementations of user agents
という文言の意味がよく理解できない。
というか、ここでの fixed
は「修正された」の方ではなく「固定された」の方だと思うのだが、「SGML 宣言上は制限値があるが、実際の UA はこの制限値を超えるデータも処理できるようにしておくべき」というような解釈で宜しいのだろうか。
鋭意まとめ中…。ちょっと渡辺さんの投稿とは方向性が違うというか、どちらかと言うと「HTML に対するフラグメント識別子の記述について」という面から見てまとめているんですが。以下概要だけ先に公開しておきます。
HTML の id 属性の値は、アルファベットを全て大文字に変換した上で評価されます。このため、例えば <div id="foo">...</div> という要素に対するフラグメント識別子は、#foo ではなく #FOO と記述しなければなりません。
このように、id 属性の値に小文字を含めることは混乱の原因となりますから、HTML 文書の著者は id 属性の値をはじめから大文字英数及び .-_: のみに変換した上で公開することが好ましいでしょう。
# id 属性値に小文字を含めること自体に文法的な問題はありません。ただし、その要素に対するフラグメント識別子は大文字に変換したものを用いることになるので紛らわしい、ということです。
また、HTML の a 要素型・map 要素型の name 属性 (以下、単に name 属性と呼びます) の値では、このような変換は行われません。このため、HTML での <a id="bar" name="bar">...</a> という記述は、<A ID="BAR" NAME="bar">...</A> と変換されて扱われます。
HTML 4.01 / ISO-HTML は「同じ要素に指定された id 属性と name 属性の値は一致しなければならない」(HTML4 12.2.3) と定めていますから、HTML において id 属性と name 属性を併記している場合には、id 属性と name 属性の値には小文字を含めぬようにしなければなりません。
なお、XHTML の id 属性ではこのような変換は行われません。したがって、XHTML の <div id="foo">...</div> という要素に対するフラグメント識別子は #foo となります。
[注意] 思考過程をだらだら書いたものなのでまとまっていません。結論は次項を参照のこと。
で、この問題の根深いところは、必ずしも形式を XHTML に変換すれば解決するわけではない、というところにあると思うのです。例えば既存の HTML 文書中に <div id="foo">...</div> という記述があったとして、これを意味を変えることなく XHTML に変換するならば <div id="FOO">...</div> と変換しなければなりません。元々の HTML がそういう意味だからです。
しかしながら、少なくとも現時点においてこのような div へのフラグメント識別子を正しく #FOO としている人はほとんどいないだろうとも思うわけで、どうしたものか。仕様の方を修正してしまえればその方がよいと思うのですが。
一応 id と name を併記しているケースでは、同一の名前空間云々の規定を削除 (ないし無視) してしまえば SGML 的に正しい互換が保たれるのですよ。また、id のみの場合なら、これは既存の文書の id を大文字に変換してしまって差し支えない (SGML 的な意味を変えぬまま好ましい記述に変更できる) のです。
ということで、既存の UA の大半は id / name の大文字小文字など区別しない…という僕の希望的観測が正しければ、既存の HTML 文書に関しては「id 値は大文字に変換し、name 値はそのまま」というのが原理的には好ましいように思います。
そもそも、名前空間を云々するならば <a id="bar" name="bar">...</a> という記述自体が不正なのですから、<a id="BAR" name="bar">...</a> に書き換えても文句はないでしょう (だって SGML 的に同じ意味なのですから)。名前空間云々を満たすように修正するなら <a id="BAR" name="BAR">...</a> でしょうが、これは修正前の name に対するフラグメント識別子を無効にしてしまうので、好ましくないことに変わりはありません。
ということは、id="bar" と id="BAR" が同じ意味である以上、わざわざ既存の文書にこの修正を加える必要もないでしょう。ただし、勿論今後も既存の文書に対するリンクを作成するユーザがいないとは限りませんし、そのユーザがこの件に関する知識を持ち合わせていなければ、大概は不適切な URI 参照を作成してしまうでしょう。そういう事例に対処するためには、id の大文字への書き換えが好ましいといえば好ましいでしょうが、少なくとも name の併記があればその必要もないでしょう (そのフラグメント識別子を name に対するものだと解釈すればよいから)。
ということで、個人的な結論デター。
こんな感じでいかがでしょうか。ご意見募集中。
ちなみに HTML 文書に対するフラグメント識別子を主体に考えた場合ですが。
# id / name 併記の場合の対処方針からすると、既存の HTML 文書を XHTML に書き換える際には、やはり id 属性値は大文字に変換してしまうべきかなぁ…。
# でも、現実問題としては修正されずに小文字含みのままになるフラグメント識別子の方が圧倒的に多いだろうから、XHTML の書き換えを小文字含みのものにしてしまうという方針をとり、それに合わせて id / name 併記の要素に対するフラグメント識別子の記述方針を name 寄りにする、という方が現実的だろうなぁ…。
[199.1] added requirements =
"SEEALSO", ps+, ("NONE"| (ps+, public identifier)+)
ISO 8879 TC2 の K.3.9 Added requirements, よく見たら public identifier を記述するためには SEEALSO の後に ps を二つ以上記述しなければならないことになっている。
といっても、実際には JIS X 4151-1992 9.1.1 にある通り ps は, 文脈上必須であっても, 区切り子又は他の ps に隣接していて省略してもあいまいさを生じないのであれば, 省略してもよい
のだが。
でもまぁ、普通に書くなら "SEEALSO", ps+, ("NONE"| (public identifier, (ps+, public identifier)*)) だよなあ。
# ていうか、一瞬「非決定的じゃん」とか思ってしまった。BNF だから関係ないんだが。でもやっぱモイキー。
なお、もちろん XHTML なら何の問題もなく小文字の ID が使えます。XML にはこの問題はありません。
というのを誤解してか、XHTML には (というか HTML ユーザ以外には)無関係な話だと捉えてるっぽい方が散見されたので、ちょっと補足。
上記引用にある通り、「XHTML 文書において id 属性を記述する場合」にはこの問題は発生しないのですが、「XHTML 文書から HTML 文書へのリンクを張る場合」には同じ問題が発生することに注意して下さい。
例えば http://example.org/foo.html で示される HTML 4.01 文書に <div id="bar">...</div> という記述があった場合、この div 要素に対するフラグメント識別子は "#bar" ではなく "#BAR" が正しいということになります。
ということは、XHTML 1.1 文書からこの要素へリンクを張るにしても、<a href="http://example.org/foo.html#bar">What is foo?</a> などと記述すると不適切な URI 参照と見なされてしまうわけです。正しくは <a href="http://example.org/foo.html#BAR">What is foo?</a> と記述しなければなりません。
要するに、リンク元の媒体か何かに関わらず、HTML 文書中の要素に対するフラグメント識別子を作成する際には、常にこの問題が絡んでくることになります。HTML ユーザでない方も、この点は頭に入れておく必要があるでしょう。
ID の属性値には ASCII が使へるものとばかり思つてゐて、此れ迄其のやうに記載して来たのですが、どうやら半角小文字の英文字は本来使へないやうです。
あくまで recommend
ですので、使えないわけではありません。というか、小文字で書いても大文字として扱われる、というだけの話なので、SGML の文法的にはどちらで書いても同じ意味になります。被参照を気にしなければ特に問題はないでしょう。
シギヤマツミの話を例に取ると、<h3 id="h15x25a">シギヤマツミ(21:11:28 JST)</h3> という記述自体には本来問題はありません。ですが、実際には北村さんも猪川さんも (変なところで例に挙げて済みません > お二方) URI 参照を http://www.petronius.biz/dasoku/2003_10b.html#h15x25a と記述していて、これが本来は不適切である、ということなのです (正しくは http://www.petronius.biz/dasoku/2003_10b.html#H15X25A)。
# 勿論、はじめから id に小文字を使わないようにしておけば、こういったミスは避けられるでしょうから、その意味で id に小文字を使わないようにする方がベターではあります。
韜晦日記, 2003-11-28 で取り上げられていますが、TR X 0052:2001 には次のような記述があります。
ID 属性で大文字・小文字を区別するかどうかは, ISO-HTML で用いる SGML 宣言の
SYNTAX NAMING NAMECASE GENERAL YES[8879 13.4.5] 規則によって制御される。YES は, 大文字への置換を行なうことを示す。すなわち, ID 値の中の小文字は, 対応する大文字で置換される。この結果として, ID 値では大文字・小文字の区別を行なわないことになる。残念なことに, NAME 属性は, ID と同じ目的にも使われてきたが, NAME 値では大文字・小文字の区別を行なう。この明らかな矛盾を解決するために, JIS X 4156 は, NAME 値及び HREF 値と ID 値との一致を決定する場合には, 大文字・小文字の区別を考慮しないことを要求する。NAME 値及び HREF 値を大文字に変換した後に, 比較を行なうことが望ましい。
この文言は、以前は ISO/IEC 15445:2000 にもありました。
The case sensitivity of the ID attribute is controlled by the SYNTAX NAMING NAMECASE GENERAL YES rule [8879 13.4.5] of the SGML declaration used with ISO-HTML. The YES means that upper case folding is to be done: lower case characters in the ID value are to be replaced by the corresponding upper case characters. This results in ID values that are not case sensitive. Unfortunately the attribute NAME hasalso been used with the same purpose as ID, and NAME values are case sensitive.
To resolve this apparent contradiction, the International Standard requires that case not be taken into account when determining matches for ID values with NAME and HREF values. Comparisons should be made after the NAME and HREF values have been folded to upper case.
しかし、この箇所は ISO/IEC 15445:2000 Second Edition でこう書き換えられています。
In order to resolve the ID/NAME case folding contradiction, we recommend that authors satisfy the competing requirements of SGML and the W3C Recommendation for HTML 4.01 by restricting themselves to the 40 characters "ABCDEFGHIJKLMNOPQRSTUVWXYZ.-_:0123456789" for IDand NAME values, and for the corresponding HREF values.
TR X 0052:2001 はあくまでも ISO/IEC 15445:2000 の邦訳ですから、恐らくこの修正も遠からず反映されるでしょう。個人的には元の記述の方がユーザライクではあったと思うのですが (他の仕様との兼ね合いの問題ですかね)。
ちなみに、RFC 2854 はフラグメント識別子に関する細かい規定を HTML 4.01 に委ねているので、HTML4 側でも同様の修正を入れてくれれば一応の解決にはなっただろうと思うのですが。W3C は、もう HTML 4.01 のメンテナンスはしないんでしょうか。
以下、W3C 関係でこの問題に触れているリソース (Hatena::agenda, 2003-11-27 より)。
いい加減しつこいなぁと思いつつ、またもこの話なんですが、仕様側の対処方法として「id 属性の型を ID にしない」というのが考えられることを何故か全く思いついていませんでした。
要素名だの属性だのを case-insensitive にしたまま id 属性値だけを case-sensitive にするようなオプションは Web SGML にもねーなどと的はずれな模索しかしておりませんで。
で、まぁ、以下すごくローカルな話になってアレですが、Geocities と isweb 用の DTD に関して id を CDATA 型に変更しました。現状では id="foo" に対する参照も #foo で可能です。
# が、現状唯一のユーザと思われるえむしぐまさんが微妙に対応し始めちゃってるくさいので今変更するのも微妙だったりしますか…?
# 技術情報: <!ATTLIST #ALL id CDATA #IMPLIED> で宣言しても良かったんですが、% id.attrib を上書き。あ、でも、XHTML 1.0 SE 対応を考えれば #ALL にすべきか…?