id と name があっちむいてぷんの件は DTD 書き換えが一番楽かしら。ただ IDREF 型の属性で何か問題がありそう。
そいつらも CDATA にしちゃえばよいと思われ。
ていうか、HTML4 には IDREF(S) 型の属性なんてないと思ってたら、実は二つもあったのか。td/th の headers 属性と、label の for 属性。全く使ったことないなぁ。
# 以下かなり私的な意見というか、むしろ駄々っ子の駄々こねのようなものなので、リアリティとかそういう切り口からは突っ込まないように。
ぶっちゃけ Flash 対 SVG という構図は全然考えていないので、そっち方面からの考察はおいておきますが、取り敢えず僕は SVG が JPEG だの PNG だの GIF だのを置き換えるものになってくれたらいいのになーと思っているわけです (すっごい無理っぽいけど)。
最たる理由は、SVG ならセマンティックなデータを画像自体に直接記述できるという点にあります。例えば、作者は誰、サイトはどこ、著作権はどうなってるなどといったメタデータを記述できますし、また、画像の代替テキストなんかも画像自体に記述可能です。要するに、画像単体のデータの質が非常に高くなるわけです (あくまで僕の主観で、ですが)。
今の一般的な画像形式だと、画像についての情報や代替テキストなどが必要な場合には、例えば XHTML などで別個に記述するほかありません。また、そういった画像に関する情報を用意しても、画像自体からその情報を参照するのは容易ではないでしょう。
現在よく用いられている方法は画像に直接 URI を書き込むというものですが、この方法では画像自体が見づらくなってしまうこともありますし、URI を文字列として扱えませんから、人が目視で確認して URI を打ち込む必要があります。また、「目視で確認して」と述べた通り、ロボットや UA による処理にも難があります (勿論 OCR を利用して処理することは可能だと思いますが)。
なお、JPEG だの PNG だのと SVG では画像データの形式自体が全く異なるので (SVG は基本的にはベクターだし)、そういう面で躊躇なさる方もいらっしゃるかと思います。そんな時には、SVG の img 要素に Base64 で JPEG や PNG 形式のデータを埋め込むなんてことも可能です。この方法なら、サイズが馬鹿でかくなったりする心配もありません。画像データ自体は JPEG や PNG のものを利用して、メタデータやテキストは XML の形式を利用するというのも、スマートな SVG の利用法ではないでしょうか。
...そんなわけで、セマンティックな画像の未来のため、SVG が流行って欲しいなーと思うわけです。ていうか、せめて、もうちょっとイラスト描いてる人たちにも SVG に興味を持ってほしいかなー。お願いします、みなさん。
# とは言え、もうちょっと気の利いたビューアが普及しないと、「使い勝手がいい」とは流石に言えないかなー。要するに、単なる理想論です。
RFC 2854 を遵守するなら、XHTML であれ text/html で serve されている文書の断片に対するフラグメント識別子は HTML 同様に解釈されるということには最初から気付いていたものの、気付かなかったことにして日々を送っていたわけですが、よく考えたら RFC 2854 は HTML 4.01 を参照しろと言っていて、その HTML 4.01 は id に関して (SGML 的に不適切ながらも) case-sensitive であると定めている (参考: Re: えび日記:「NAMECASE GENERAL YES の意味」) 以上、HTML 互換の XHTML 1.0 文書の id に関しても case-sensitive に解釈されるものと考えてよかろう、いやむしろ考えるべきだ、そう考えなきゃならないったらならない! というような素晴らしく恣意的な言い訳もとい結論に到達することができ、良かった良かったと胸をなで下ろしている次第です。落着。
JIS X 4151-1992 を読んでいて、ちょっと困ったことに気が付いた。要素型宣言、内容モデル、モデル群、出現標識辺りの式、表3、及び認知様相の備考などを参照する限り、出現標識 opt 及び rep は認知様相 GRP でしか認知されない。
認知様相の項の備考にも述べられている通り、GRP というのは grpo を認知してから grpc を認知するまでの様相のはずだ。とすると、内容字句としてでなく、内容モデルとして直接モデル群を記述する場合、grp の直後に * や ? を記述しても、rer や opt としては認知されないということになる。つまり、XML で認められている <!ELEMENT foo (#PCDATA|bar)* > という宣言は文法違反ということになってしまう。
どこか他の箇所で例外扱いされているか、もしくは追補などで訂正されているかするならよいのだが。あと、ISO 8879:1986 ではどうなっているだろうか?
# ついてでに言うと、plus は GRP MD になっているが、この MD は添加要素の指定・出現についての plus を意図したものじゃないかと思う。
grpc - SuikaWiki によると、grpc の直後では、出現標識が認知されるかもしれません
とのことだが...ソースはないのかしらん。実際の記述例とか、パーザの実装例とか、XML での定義とかからすれば、もちろんそうでないと困るのだが。
しかし、こんなこと気にしてる辺り、流石 SuikaWiki だ。笑い。
区切り子の grpo 及び grpc の均衡対又は区切り子の dtgo 及び dtgc の均衡対によってくくられた引数の一部分。
名前群, 名前字句群, モデル群, データタグ群及びデータタグひな形群の5種類がある。名前, 名前字句又はデータタグひな形群は, 群を含むことはできない。しかしモデル群はモデル群を含むことができ, データタグ群はデータタグひな形群を含むことができる。
定義では区切り子の grpo 及び grpc の均衡対
と言っちゃってるのだけど、備考でモデル群も群に含めているからなあ。群の中で認知する
という文言の群という語はモデル群も含むものとして考えよう。そういうことにすれば、モデル群の中にある <!ELEMENT foo (#PCDATA|bar)* > の * は rep として認知して差し支えないことになる。
# 認知様相の解釈上の well-defindness が失われてしまうが、構文的な意味合いは変わらないということで納得するしかあるまい。というか、この定義じゃまるっきり文脈依存区切り子だと思うのだが。
鳩丸の SGML の省略タグ機構への突っ込み。
JIS X 4151-1992 はタグの省略に関して次のように定めています。
[引用]要素の開始タグは, その要素が文脈上必須であって, しかもそこに現れうる他の形式の要素がどれも文脈上任意選択である場合, 省略することができる。ただし, 次の (1)〜(2) のときを除く。
(中略)
要素の終了タグは, 次の (1)〜(3) の直前に位置する場合, 省略することができる。
これを踏まえて、次の記述において HEAD の終了タグと BODY の開始タグがどこに補われるかを考えてみます。
[引用]<HTML> <HEAD> <TITLE>自明でないと省略できません</TITLE> <SCRIPT type="text/javascript"> <!--謎のスクリプト--> </SCRIPT> <P>本文なのですが。</P> </BODY> </HTML>
HEAD は TITLE も SCRIPT も内容に持つことができますから、これらの要素の前に HEAD の終了タグが補われることはありません。これに対して、P 要素は HEAD 要素の内容になりえません。つまり、HEAD の終了タグは 6.3.1.2 (3) に従って P 要素の直前に補われることになります。
さて。いま、HEAD の終了タグが P 要素の直前に補われたとします。すると、HTML 要素型の内容モデルに従い、HEAD 要素の直後には BODY 要素が文脈上必須
になります。ということは、6.3.1.1 に従ってここに BODY の開始タグが補われることになります。
結局、この記述は次の完全タグ付きの記述と等価ということになります。
<HTML> <HEAD> <TITLE>自明でないと省略できません</TITLE> <SCRIPT type="text/javascript"> <!--謎のスクリプト--> </SCRIPT> </HEAD><BODY><P>本文なのですが。</P> </BODY> </HTML>
つまり、この記述は HTML 4.01 として妥当です。
ちなみに、PC Tips の HTML 文書を書く際の注意點 (2003年12月15日 削除) (いつの間にか消えてしまった) (削除ここまで)にも(HEAD が) script や object と云つた要素を含む時には、終了タグが正常に補はれない可能性がある
という記述がありましたが、この記述で作者の意図通りに補われない可能性があるのは、HEAD の終了タグではなく、むしろ BODY の開始タグの方です。(2003年12月15日 追記) (って、これひょっとして HTML ブラウザの実装の話だったりしますか?) (追記ここまで)
同様に、次の記述がどのように解析されるか考えます。
[引用]<TABLE> <THEAD> <TR><TH colspan=2>いきもの <TR><TH>えび<TH>かに <TR><TD>おいしい<TD>やっぱりおいしい </TABLE>
TR, TH, TD は THEAD の内容となりますから、これらの要素は THEAD を終了させません。6.3.1.2 (2) に従って、TABLE の終了タグの直前に THEAD の終了タグが補われることになります (TR, TH, TD の終了タグの補完は 6.3.1.2 (3) による)。
<TABLE> <THEAD> <TR><TH colspan="2">いきもの</TH></TR> <TR><TH>えび</TH><TH>かに</TH></TR> <TR><TD>おいしい</TD><TD>やっぱりおいしい</TD></TR> </THEAD></TABLE>
ここで、TABLE の内容モデルから、THEAD の直後には TBODY が文脈上必須
になります。しかし、この記述では TBODY 要素の実現値の内容が空
ですから、6.3.1.1 (2) の通り、TBODY の開始タグを補うことができません。
従って、この記述は「文脈上必須である TBODY 要素が省略されている」という理由でエラーになります。つまり、省略が自明でない
という理由でエラーになるわけではないのです。
以下は実際の解析の例です。
上記文書の、パラメタ実体参照の解析のくだりの補足。
[引用]内容モデル = (モデル群 |"ANY"), (ps+, 例外)? ―(126) モデル群 = grpo, ts*, 内容字句, (ts*, 接続子, 内容字句)*, ts*, grpc, 出現標識? ―(127) 内容字句 = 素内容字句 | モデル群 ―(128) 素内容字句 = (rni, "PCDATA")| 要素字句 | データタグ群 ―(129) 要素字句 = 共通識別子, 出現標識? ―(130)[引用]
(4) マーク宣言の中での参照は, 0 個以上の連続する完全な引数 (その間の ps 分離子を含む。)で置換するか, 群の中にあって 1 個以上の連続する完全な字句 (その間の ts 分離子及び接続子を含む。) で置換するかしなければならなない。
つまり、次の例は不正です。
<!ENTITY % baz.qname "baz" > <!ELEMENT foo (bar, %baz.qname;+) >
次の例は妥当。
<!ENTITY % baz.qname "baz" > <!ELEMENT foo (bar, (%baz.qname;)+) >
次の例も妥当。
<!ENTITY % baz.qname "baz" > <!ENTITY % foo.content "(bar, %baz.qname;+)" > <!ELEMENT foo %foo.content; >
XHTML 1.1 の DTD はこの記述を利用しています。パラメタ実体参照を咬ませているからエラーにならないのであって、直接内容モデルに %baz.qname;+ と記述すればエラーになることに注意して下さい。
ちなみに、XML にはこの辺りの規則についての明確な記述はありません。何らかのエラーになるのは間違いありませんが、invalid なのか not well-formed なのかも判然としない状態です。
内容模型 - SuikaWiki でご指摘を頂きましたが、XML には (実体値として出現した場合以外での) パラメタ実体参照を展開する際、前後に #x20 を付加したものとして扱うという規定があるそうです (これは知りませんでした...)。ということで、XML ではこの手の記述は not well-formed になります。
'xml' で始まる名前NAME は, 字 (letter) 又は幾つかの区切り文字の一つで始まり, その後に字 (letter) , 数字, ハイフン, 下線, コロン又はピリオドが続く。これらの文字を名前文字という。文字列 "xml" で始まる名前, 又は正規表現 (('X'|'x') ('M'|'m') ('L'|'l')) にマッチする任意の文字列で始まる名前は, この規格の現在の版又は将来の版での標準化のために予約する。
XML では、'xml' で始まる名前は予約されています。ID 型の属性値は名前として記述することになっていますから、XHTML で id="xml-foo" などという記述をすることは不適切です (id="XML-foo" は OK, id="XML" は NG (2003年12月13日 追記) ...と思ったら、どっちも NG でした (追記ここまで))。
パラメタ実体名についても同様で、不用意に %xml.foo; などとやらかすべきではありません。やっちゃっている規格が結構ありますが (DocBook XML とか、XML Events とか)、本来は不適切です。
# 分かってるんだけどやっちゃうなあ。ということで、あらためてメモ。
ap:banner 属性のスキーマ実装が無いようなので、書いてみました。
所有者識別子は洒落というか苦肉の策です。version 属性用に公開識別子は書かなきゃならんのですが、適当な値が思いつかなかったもので。-//NyanNyanHanten にしちゃって良いかしらん?
'xml' で始まる名前 #2
と書かれていますけど、どちらも駄目ではありませんか。id="XML-foo" は OK, id="XML" は NG
おお、わざわざ JIS から引用しておいて訳を読んでませんでした。原文の記述はこうなんですよ。
[引用]Names beginning with the string "xml", or with any string which would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization in this or future versions of this specification.
僕はこれを「"xml" で始まる名前、または (('X'|'x') ('M'|'m') ('L'|'l')) にマッチする名前」が予約名と誤読していたんですが、よく読んだら「(('X'|'x') ('M'|'m') ('L'|'l')) で始まる名前」ですね (JIS X 4159 はちゃんと訳してるのに...)。失礼しました。
あれこれポップアップの名前空間名は http://www.remus.dti.ne.jp/~a-satomi/ap って書いてあるけど、この ~ は overline (‾) じゃなくて恐らく本来は tilde (~) ですよね (参照: W3C信者にサイトを正しい記述に直して貰うスレ3, >>111-115)。
つまるところ、Shift_JIS の文書であれこれポップアップの語彙を利用するためには、名前空間宣言を xmlns:ap="http://www.remus.dti.ne.jp/~a-satomi/ap" ではなく xmlns:ap="http://www.remus.dti.ne.jp/~a-satomi/ap" などと書く必要があるということになります。
ちなみに xmlns:ap="http://www.remus.dti.ne.jp/%7Ea-satomi/ap" とは書けないので注意して下さい。名前空間名はあくまで単なる CDATA として評価されるので、URI エスケープを利用すると別の名前空間名と見なされてしまいます。
Namespace in XML 勧告に適合しつつ名前空間に属さない語彙を利用するためには、名前空間名を空文字列とするデフォルト名前空間を宣言する必要があります。
例えば SGML で(?)用いられていた embed という語彙は、(少なくとも僕の知る限り) 明確な XML 名前空間には属していません。従って、この embed という語彙を XHTML 文書などに埋め込んで使うためには、この語彙が名前空間を持たないことを明示するため <embed xmlns="" ... /> と記述しなければならないわけです。
まぁ、別にオレ名前空間に属するものとして定義しても (<embed xmlns="http://www.satoshii.org/embed" ... /> とかね) 構わないと言えば構わないのですが (実は XHTML 1.1 も Ruby モジュールの取り込みでこういうことをやっている気がする)。とりあえず http://www.w3.org/1999/xhtml には embed などという語彙は定義されていませんから、<embed xmlns="http://www.w3.org/1999/xhtml" ... /> としてはなりません。
ちなみに接頭辞を付けて <foo:embed xmlns:foo="" ... /> と書くことはできないので注意して下さい。こういう記述は Namespace in XML では認められていません (Namespace in XML 1.1 でも違う意味で不可)。