マーク区間の状態見出し語指定 (<![ ここ [) にパラメタ実体参照を書けるということは、XML 1.0 でちゃんと明言されていたろうか? ということがちょっと気になり、仕様書を確認してみた。
- [61] conditionalSect ::= includeSect | ignoreSect
- [62] includeSect ::= '<![' S? 'INCLUDE' S? '[' extSubsetDecl ']]>'
- [63] ignoreSect ::= '<[' S? 'IGNORE' S? '[' ignoreSectContents* ']]>'
式自体はこう。で、その後に If the keyword of the conditional section is a parameter-entity reference, the parameter entity must be replaced by its content before the processor decides whether to include or ignore the conditional section.
という註がついていた。微妙に紛らわしい気がする。というか、こういう書き方だと、<![ ここ [ に他のマーク付けを書けるのかどうかとか分かんないよなあと思った。
などと考えていてふと思ったのだが、<![ ここらへん [ にコメントを書いたりはできるのだろうか(<![ <!-- こんな感じ --> [)。いや、XML では流石に無理だろうが、SGML なら書けそうな気がしないでもない。調べてみた。
- マーク区間宣言 = マーク区間開始, 状態見出し語指定, dso, マーク区間, マーク区間終了 ―(93)
- 状態見出し語指定 = (ps+, (状態見出し語 | “TEMP”))*, ps* ―(97)
…パラメタ実体参照を書けるんだから、s じゃなくて ps か。… ps って、アレ? 確か…
- ps = s | Ee | 引数実体参照 | 注釈 ―(65)
…注釈?
注釈宣言、ではない。コメントは書ける。書けるけど、<![ IGNORE <!-- こう --> TEMP [ ではなく、つまり <![ IGNORE -- こういうこと -- TEMP [ である。
# 随分前にマーク区間の]] -- ココ -- > にコメントを入れたりはできない(リンク先の内容は今読むと激しく不正確だなぁ…)、ということを調べたことがあったが、<![ -- ココ -- [ にコメントを書けるかなんてことは全く考えなかったなあ。奥が深い。
SGML の処理命令は PIC (規格参照具象構文では "
>") が現れた時点で終了します。ですから PHP の大なり演算子は代わりに>か>と書いても認識してくれると期待したのですが、残念ながらParse error。
処理命令の中身は CDATA 扱いで、pio の出現後に区切り子として認知されるのは pic だけなので、文字参照が使えないのはしゃーないんじゃないかと(でも、スクリプトエラーにはなっても parse error にはならないんじゃないでしょうか)。
この辺の事情は HTML4 の script 要素中に </名前開始文字 を書けないのと良く似てると思うわけですが、というか、PHP 側にはそれ用のエスケープとかないんでしょうか? 無いのであればやはり 左辺値と右辺値を交換
というのが現実的かと。
# XML が DELIM PIC "?>" なのはそういう理由からなのかな? なるほど。
"iモード対応XHTML" なる規格が出ているらしい。が、DTD が見付からないとか何とか。しかも、その筋(謎)の情報によれば、em だの q だの abbr だのは使えないらしい。
個人的に気になったのは、わざわざ 参照ドキュメント
として Modularization of XHTML を提示していて、かつ -//i-mode group (ja)//DTD XHTML i-XHTML(Locale/Ver.=ja/1.0) 1.0//EN という FPI を用いているという点。
どう考えても、普通のネーミングセンスでこんな不自然な位置に "XHTML" という語を持ってくるはずがない。とすれば、当然 Modularization of XHTML の次の記述を踏まえてこういう FPI を付けたと見なすのが妥当であると思われる。
Only XHTML Host Language conforming documents should begin the public text description with the token XHTML. The public text description should contain the string XHTML if the document type is Integration Set conforming.
つまり、"iモード対応XHTML" は XHTML ホスト言語であると考えられる。とすると、その定義に従って、"iモード対応XHTML" は少なくとも Structure module (html, head, title, body), Hypertext module (a), Text module (abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var), List module (ul, ol, li, dl, dt, dd) という四つのモジュールを含んでいるはずなのだが…。
上記の文書を修正しました。もっと早く修正するつもりだったのに…。
ここ二週間ほど、現状の isweb で valid な HTML を公開するのは無理だろうと思っていたのだが、解決策を思い付いた。
以前は <td></form></td> というようなコードだったので、<!ELEMENT td - O (form) > <!ELEMENT form O O ANY > というような定義をして無理矢理 valid にしていたわけである(無料サーバ向けの HTML 定義(4) 参照)。が、いつの間にかこれが <td></form><a></a></td> のような記述に変わってしまった。こうなってしまうと、前述のような方法ではどうやっても </form> を正当化するのは無理である。
そんなわけで、この件については半ば放棄しつつ他の作業をしていたのだが、何か Strict-HTML スレで折良く無料サーバ云々の話が出ていたので、微妙に愚痴ってみた。そしたら 解決が可能な予感
とか言われ、おみゃー軽く言うなあなどと思いつつ、何となくそれが切っ掛けになってリトライすることに。で、ふと思い付いた。短縮参照を使えば何とかなるんではないかと。
短縮参照というのは、― 中略 ― そう言えば随分以前に解説(短縮参照について: 結構記述がアレなので非推奨気味というか書き直そうと思ったまま忘れてお蔵入りになっていたのだが)を書いたことがあったので詳しくはそちらを参照してもらうとして、要は特定の文字列を他の文字列に置換するための仕組みである。つまり、</form> という文字列を空文字列に置換してしまおうと、そう考えたわけである。
まずは SGML 宣言で SHORTREF SGMLREF "</form>" と宣言して、</form> を区切り子として定義する。SGML では、より長い区切り子を優先的に認識するので、文書インスタンスに </form> と記述しても </ は etago とは見なされない(もっとも、仕様書にも「こういう紛らわしい真似はするな」という注意書きはある)。
あとは、DTD に以下のような宣言を加えればよい。
<!ENTITY etagf "" >
<!SHORTREF fmap "</form>" etagf >
<!USEMAP fmap td >こうしておけば、td 要素の内部にある </form> という文字列は、全て「なかった」ことになる。勿論、この定義の副作用として「form の終了タグが認識されない」という現象が生じるので、泥縄式に form 要素の内部にある </form> を </form > に置換するなどする必要があるが。
# </form> に置換すると無限ループ ― とは言わないが要するにそのような状態(再帰呼び出し)になってしまう。ENDTAG "form" でも全く同様。CDATA </form> に置換すると、これは文字データ扱いなので終了タグとは見なされず、やはり不適当。結局、終了タグにも空白を記述可能という構文を活かすのが最もマシな(もしかすると唯一の?)策かと。
そもそも匿名ブロックボックスというのは「display:block; の要素と兄弟関係にある文字データ(を取り囲むボックス)」を指す CSS の用語であって、HTML の用語ではないわけで。HTML 的な見地から言うのであれば「ブロック要素とテキスト(インライン要素)の混在」などと言うべきだと思うわけだが。
で、取り敢えず書いておくと、XHTML 1.1 以前の X/HTML 文書に「ブロックとテキストの混在」があるのはよろしくない。確かに DTD ではそのような記述が認められているが、それはそういう記述を意図したものでは有り得ないと思う。
大体、もし「ブロックとテキストの混在」が認められるのであれば、p 要素型の内容モデルが真っ先にそういうものになっていたはずである。p ですらそれが認められないのに、li だの td だのだけで率先して認められる理由がない。
では、何故 HTML 4.01 などの DTD は li や td の内容に「ブロックとテキストの混在」を許可しているのか。これは、そもそも SGML が ((%inline;)*|(%block;)+) のような内容モデルを非推奨 (XML では禁止)としているからだろう。
ちなみに、SGML で実際に <!ELEMENT li - O ((%text;)*|(%block;)+) > といった定義を行うと、<li><p>foo</p></li> は valid だが <li> <p>foo</p></li> は invalid と見なされる。これは、#PCDATA を内容に持ちうる要素型は、その内容中の全て位置で混合内容を持ちうるものとして扱われるためである(詳しくは後述)。
ということで、li だの div だの del だのに対しては、「テキスト(インライン要素)のみ」か「ブロック要素のみ」を内容として記述すべきなのだが、DTD でそういう定義をするのは非推奨であり、かつ文法も無駄に複雑化してしまうから、やむを得ず混在が可能な定義になっている、と見なすのが適切なのではないかと思う。
前項に関連して。恐らく XML Schema を念頭に置いての設計なのだろうが、XHTML 2.0 の草案では object の内容モデルが (caption?, (#PCDATA | %Flow.mix; | param)*) となっている。このモデルは前述のように XML DTD では表現不可能であるから、DTD では制約を緩めて (#PCDATA | %Flow.mix; | param | caption)* として定義することになる。
SGML/XML DTD では、ある要素の内容を検証する際、内容の先読みを必要とするモデルを定義することはできない。例えば、((a, b) | (a, c)) という内容では、内容の最初の a が (a, b) の a とマッチするのか、(a, c) の a とマッチするのかは、a の弟の要素を先読みしないと決定不可能である。
これと同様に、SGML/XML DTD では空白文字の扱い(データとしての (#x20 | #x9 | #xD | #xA)+ かマーク付けとしての s か)も内容の先読みなしに決定可能である必要があった(ものと思われる)。<!ELEMENT ul (li+) > と定義された場合の <ul><li> と <ul> <li> は等しく扱われるが、この時、パーザは「DTD の定義から空白文字の処理方法を決定 → 空白文字を s と認識 → li が内容モデルにマッチ → valid」という手順で処理を行っているのである。
前述の #PCDATA を内容に持ちうる要素型は云々
という規則はこのためのものであり、SGML DTD での (caption?, (#PCDATA | %Flow.mix; | param)*) という内容モデルに対しては、取り敢えず「空白文字はデータと見なす」ことにして処理を行うことになっている。
従って、<object> <caption> と記述すると、開始タグ直後の空白文字がデータと見なされるため、object の内容モデルは (#PCDATA | %Flow.mix; | param)* とマッチし、caption の出現はエラーとなる。直感的には <object> <caption> という記述は valid に思えるが、これを valid と見なすためには後続の内容の先読みが必要になってしまうのである。
ちなみに、いわゆる Well-Formed な XML 文書では ― というか XML 文書を non-validating processor で処理する場合には ― 全ての要素型は ANY と定義されているものと見なされるので、あらゆる要素内の空白はデータとして扱われることになる(例えば <ul><li> と <ul> <li> は異なる意味を持つ)。
XML Schema や RELAX NG などでは (caption?, (#PCDATA | %Flow.mix; | param)*) のような内容モデルの検証も可能であるようだが、仕組みは知らない。これらのスキーマは基本的には Well-Formed な XML 文書を検証するためのものであるから、そもそも Valid XML でいうところの「文字データとしての空白文字とマーク付けとしての s」に相当する概念自体存在せず、空白文字を全てワイルドカードのように見なして処理を行っているのかも知れない。