一つめについて。石川さんは、XHTML の方が簡単だとおっしゃっています。その根拠が、SGML より XML の方が簡単だから、と。これって、初心者に、いきなり XML なり SGML の全貌を教えるつもりって事ですか。少なくとも私は初心者にものを教えるときに、相手のレベルにもよりますが、技術的な根幹からは教えませんが。
基礎的な構文に関して言っても、HTML は SGML の構文、XHTML は XML の構文でそれぞれ説明することになると思いますが。例えば、「HTML では img や meta は終了タグを書いてはならない」「checked="checked" は単に checked とも書ける」といったような例外の理解は、中々本質的には理解し難いものです。
多くの場合、HTML のマーク付けは「<foo>...</foo> で囲まれた部分が foo 要素(の内容)である」というように解説されると思います。ここで、<foo></foo> というように「要素内容が空である」要素を「空要素」と呼ぶわけです。では、<td></td> では普通終了タグを記述するのに、 <img></img> では逆に終了タグが禁止されているのは何故なのでしょうか。
このことの「何故」を解説する必要があるのかないのかは、解説者の好みによるのでしょうが、純粋に「何故」という疑問が生じる部分であると思います。正直なところ、僕には「そう決まっているから」以上の説明はできませんし、実際この制約は不要なものであったと思います。だからこそ、XML ではこの制約がなくなっているわけですし。
他の部分に関しても、XML ではこういう「(不思議な)例外」がことごとくなくなっていますから、解説も理解も至極単純になっていると思います。それと、たとい SGML と XML の難易度が同レベルであったとしても、SGML では(現在普及している) XML の機構を使用できない云々の件で述べた通り、今更 SGML を覚えるよりはまず XML を覚えた方が良いと思います。
今囘の論爭は、文章の節構造を明示すべきかしなくても良いか、の論爭なのであつて、「ISO-HTML」と XHTML とが對決してゐるのではない。
「明示してはならないのか、明示してもよいのか」であるように思います。前者が ISO-HTML で後者が XHTML(というか、ISO-HTML 以外の X/HTML) ですね。双方の言語の本質的な制約についての対決ですから、羊頭狗肉
というのは違うのでは。
それと、HTML と XHTML ではどちらが好ましいのか、という部分が無視されているようですが。
HTML 4.01 Strict で「省略可」とされる要素を全て省略した文書が、XHTML 1.x に合致しなくとも XML の整形式の文書となつてゐる事はあり得るのだし、さう云ふ文書を「XHTML 派」の方々は批判しますか。讀んで譯がわからないとは言はせない。
HTML 4.01 でも、空要素さえ書かなければ常にそういう文書にすることができますから、それは勿論批判しません(文書インスタンスについては)。しかし、meta も link も記述できないことになりますが、それでも構わないのでしょうか。あり得る
とは仰いますが、それはつまるところ「通常そうはならない」ということなのではありませんか。
俺の「PC Tips」の記事は、どう見ても「整形式の XML 文書を記述する基本」を教へてゐるものだが。
旧来の SGML と XML との共通部分についてはそうかも知れませんが、それは「マーク付けの基本的な概念」が両者でほとんど共通する以上、当然と言えば当然です。逆に、旧来の HTML と XML とで「決定的に異なる」部分については、野嵜さんはXHTML では
と XML の方を例外的な扱いになさっています。
結局、野嵜さんは HTML と XHTML でどちらが推奨されるべきとお考えなのでしょうか。そこが一番の疑問なのですが。
だが、今迄溜め込んで来た世界各地のウェブデータをどう始末をつけるかが此れからの一つの課題になるだらう。此れは簡単な問題ぢやないよね。
だからこそ、既存のデータはともかく、新しく作成するデータについては始めから始末
(というか「処理」)の必要がないようにしておくのが好ましいと思うのです。これまでが、あるいは今がそうだからといって、これからもどんどん溜め込んで
いくというのは、やはり推奨されるべきではないと思います。
「思い立ったが吉日」と言うように、こういうことは早いうちに済ませてしまうことが肝心なのです。XML (XHTML) を処理するための環境は、既に SGML (HTML) を処理するための環境よりも整っています。
私は、文書構造の書き方の示唆を仕様に明記すべきか否か、だと思っていました。まぁ、これに関しては石川さんしか反対していないけど。
別に反対してなんていませんよ。文書構造の書き方の示唆を仕様に明記すべき
という点については同意です。そこで明記されている文書構造
が、ISO-HTML のものはおかしいと思う、という話です。(見出しを含む div を)万人が機械のためにわざわざ書く必要はないと思います
というのも同意で、問題は「書くことを禁止する必要はあるのか」ということです。僕はこちらの必要
こそない
と思います。
「要素内容が空である」要素を「空要素」と呼ぶわけです。では、
<td></td>では普通終了タグを記述するのに、<img></img>では逆に終了タグが禁止されているのは何故なのでしょうか。いらないからじゃないですか。私は逆に、中身が無いのになんで終了タグが必要なのかを説明するほうが難しいと思いますけど。機械に理解させやすいように書くんだよ、なんていって判る人は、すでに初心者じゃないでしょう。
いやいや、「foo 要素の内容を <foo> と </foo> で括る」というのがマーク付けの大前提です。その内容が偶々空だったというだけなんですから、中身が無いのになんで終了タグが必要なのか
なんて疑問は普通生じません。そもそも XHTML の場合には、最初からタグの省略という概念が存在しないのですから。
HTML の場合にも、まずは省略しない書き方というのが基本であるはずです。その上で、「タグの出現箇所が(DTD から)自明な場合には、p などの終了タグは省略してもよい」という流れになるのが普通だと思います。ところが、img などでは最初からさしたる理由もなく「終了タグは省略しなければならない」になってしまいます(p 同様「してもよい」ならまだ頷けるのですが)。
# SGML なんかの解説では、初っ端から「終了が明らかな終了タグは省略してよい」なんて書いているものもありますが、これはその後で DTD を書くことを前提としているからです。HTML の場合にはこの流れの解説は余り好まれないでしょう。
それに、<td></td> という空のセルを見て、中身が無いのになんで終了タグが必要なのか
なんて思ったりはしないでしょう。空の img も空の td も、本質的には同じ種類のものです。img は EMPTY、td は (%flow;)* というように宣言されていますが、後者は要するに (#EMPTY | (%flow;)+) の意味なんです(勿論 #EMPTY という記述は不正ですが)。
# だからこそ XML では <td/> という記述も認められているわけで。内容モデルが EMPTY か (%flow;)* かというのは関係なく、中身が空の要素は空要素なんです。あるいは <!ELEMENT img EMPTY > という記述を <!ELEMENT img () > と見なしてもよいと思います(勿論 () という記述も不正ですが)。
# なお、旧来の SGML のように、終了タグの記述が禁止されている空要素(例えば内容モデルが EMPTY の型の要素)を特別扱いする場合には、本来これを強制空要素と呼んで区別することになっています(一般的には「空要素」という言葉が「強制空要素」の意味で使われるようですが)。
# ちなみに、XML ではこういう特別扱い
の必要がないので、勧告にも「強制空要素」という語は使われていません。HTML 4.01 勧告などに「強制空要素」という言葉が使われていないのは、恐らく HTML 4.0 勧告の時点でまだこの語が定義されていなかったためです(まあ全体的に HTML 4.01 の勧告は SGML 的には厳密でない語句の使いかたをしているのですが)。
いやいや、内容を括るのが大前提だからこそ、括るもンがないと疑問は生じるのです。
それじゃ括るものがない
空の td 要素の場合はどうなりますか。同様の疑問は生じないのでしょうか(と、僕はHTML 再考(4)にあらかじめ述べていますが)。
それと、ISO-HTML の文構造云々についても、だから ISO/IEC 15445 は駄目なのである(3)に述べた通りです。
ISO-HTML では、この正しい文書構造の示唆が、見出し要素（H1〜H6 要素）と、それに対応する内容物(若しくは本文)要素(DIV1〜DIV6 要素)で示されています。
なるほど、示唆
はしているかも知れませんが、しかし ISO-HTML が実際に DTD に明示しているのは、むしろ「階層構造を示すマーク付けの禁止」ということ、ただそれだけです。見出しの出現順についても、実際に明示されているわけではありません。全ての ISO-HTML 文書が Pre-HTML の段階を経て作成されているとすれば、見出しは一応整列するかも知れませんが、それ以上の構造は全く明示できないのです。
ISO-HTML は、HTML 4.01 をベースに、文書の階層構造を特に強調した仕樣です。見出しを基準に、全ての段落が階層化されてゐると看做されます。
この考えは全くの誤りなのです。実際にパーザが読むのは、見出しと段落に関して全く階層構造の明示されていない ― 明示の禁止されている ― 文書でしかありません。見出しのレベルから後続の段落のレベルを判断する機能など、SGML には存在しません(*1)。このことを指摘したのが次の段落です。
もし、この「要素」 ― すなわち「見出しを含む div」 ― をマーク付けせず、しかもそれでなお「見出しから見出しまでの範囲(例えば div1 疑似要素のような)」を扱うことを期待するのであれば、それは最早 SGML などではない。
で、「階層構造を明示しなくともよいとも思うが、明示した方が好ましいと思う。だから、これを積極的に禁止することはない」ということも続けて述べています。
もちろん禁止する必要はないし、禁止もしていません。見出しを DIV 要素で括ると ISO-HTML ではなく、HTML 4.01 になるというだけです。
だから、僕は「積極的に ISO-HTML を推奨する理由はないのでは」と述べているわけです。
改めて言いますが、ISO-HTML で表現可能な構造は、基本的に XHTML 1.1 でも表現可能です。HTML と XHTML では XHTML の方が好ましいということは言うまでもありません。次の二つのリソースは、このことを示す良いサンプルです。
両者のソースでは、ほとんど同様の構造化がなされています。だからこそ、前者は HTML であり後者は XHTML であるという決定的な差違が際立っているのです。後者のリソースは XML パーザで解析して、XSLT に掛けることも簡単にできます。しかし、前者のリソースは SGML パーザで解析しなければなりませんし、XSLT 相当の変換には DSSSL などを用いるしかありません。
一連の議論において僕が言いかったのは、「XHTML を使える人は XHTML を使って欲しい」ということです。ISO-HTML の構造は XHTML でも表現可能です。敢えて HTML に留まる理由があるのでない限り、文書は XHTML で書かれていた方が好ましいということに、何か異存がおありでしょうか。
XHTML の基本の理解は極めて難しいものである、というのならまた話は別でしょうが、少なくとも XHTML の基本は HTML の基本よりも簡単です。ですから、これから X/HTML を学ぼうという人は、最初から XHTML を学んだ方がロスも少ないしより実用的でもあるでしょう、ということを述べてきたのです。HTML を知っている人が XHTML を修得することも、1時間足らずで可能であると思います。
DDT さんは、XHTML であることを捨てても ISO-HTML を使うことに、ISO/JIS 準拠ということ以外の何かしらの意義があるとお考えなのでしょうか。もしくは、XHTML の方が HTML よりも難しいとお考えなのでしょうか。
SGML には、実はこのような処理を行うランクという最小化機構も存在します。しかし、ISO-HTML はこの機構を利用しているわけではありません。
SGML 宣言で RANK YES が宣言されているとき(基本 SGML は RANK NO)、次のような要素型宣言を行うと、要素名の後半の数字が「ランクを示す接尾辞」としてパーザに認識されます。
<!ELEMNT (h|p) 1 - - (%text;) -- 要素名は h1 と p1 -->
<!ELEMNT (h|p) 2 - - (%text;) -- 要素名は h2 と p2 -->
<!ELEMNT (h|p) 3 - - (%text;) -- 要素名は h3 と p3 -->このような宣言をすると、見出しや段落のランクが変化するとき以外には、ランク接尾辞を省略できることなっています。
<h1>見出し</h1>
<h2>見出し</h2>
<p>段落</p>
<p>段落</p>
<h3>見出し</h3>
<p>段落</p>
<p>段落</p>
<h>見出し</h>
<p>段落</p>
<p>段落</p>
<h2>見出し</h2>
<p>段落</p>
<p>段落</p>
<h3>見出し</h3>
<p>段落</p>
<p>段落</p>
<h>見出し</h>
<p>段落</p>
<p>段落</p>このマーク付けは、次のマーク付けと等価です。
<h1>見出し</h1>
<h2>見出し</h2>
<p2>段落</p2>
<p2>段落</p2>
<h3>見出し</h3>
<p3>段落</p3>
<p3>段落</p3>
<h3>見出し</h3>
<p3>段落</p3>
<p3>段落</p3>
<h2>見出し</h2>
<p2>段落</p2>
<p2>段落</p2>
<h3>見出し</h3>
<p3>段落</p3>
<p3>段落</p3>
<h3>見出し</h3>
<p3>段落</p3>
<p3>段落</p3>HR: structure or presentation?HTML 4.01 では、hr 要素の定義は次のようになっています。
The HR element causes a horizontal rule to be rendered by visual user agents.
HR 要素があると、視覚系ユーザエージェントは罫線をレンダリングする。
実は区切り
という言葉は一切出てきません。意味的に大きな区切りがある
ことを示すのは div 要素型です。区切りがあることを水平線
で示したい場合には、スタイルシートによって表現すべきなのではないでしょうか。これは、b や i が強調を示すものではないのと同様です。XHTML でも、hr 要素型は b や i や big などと同様の Presentational Elements
として扱われています。
次に br について。リストまではいかなくても、リストのように改行して羅列する場合
というのは今ひとつ想像できなかったのですが、定型詩のようなものを表示したい場合
には pre 要素としてマーク付けすべきなのではないかと思いました。
hr にせよ br にせよ、それでしか表現できない場合、というのもないわけではないかも知れませんが、やはり基本的には他の要素として示されるべきものであるように思います。
# hr に対して意味的に大きな区切りがあるときは、水平線を書きます
→物理の陰に論理が隠れていたのです
という解説が成り立つのであれば、font に対しても「強調される箇所があれば、文字色を赤にすることで表現することもあります」→物理の陰に論理が隠れていたのです
という解説が成り立つことになってしまいます。
# この解説の問題点は、物理マークが好まれない理由を忘れてしまっていることにあります。物理の陰に論理を隠して
しまってはいけません。HTML は論理を明示するためのものなのですから。強調要素の場合と同様に考れば、「hr … div 要素と見なしましょう！ ちなみに水平線はスタイルシートで。」という具合になるのではないかと思います。
だから ISO/IEC 15445 は駄目なのである(3)に書かれているのは、機械処理のために DIV 要素で括るべきだ、って話しだけだと思いますが。
処理が必要になる時点で、その範囲は間違いなく要素を形成しています。明らかに div 要素として存在しているものだから div 要素として明示すべきだ、と述べているのです。ISO-HTML は、要素として確実に存在しているものを「存在しない」と見なす構造を採用しています。
ISO-HTML では、この正しい文書構造の示唆を、見出し要素（H1〜H6 要素）と、それに対応する内容物(若しくは本文)要素(DIV1〜DIV6 要素)で示されています。
なるほど、
示唆はしているかも知れませんが、しかし ISO-HTML が実際に DTD に明示<!-- (勿論このしているのは、むしろ「階層構造を示すマーク付けの禁止」ということ、ただそれだけです。見出しの出現順についても、実際に明示されているわけではありません。全ての ISO-HTML 文書が Pre-HTML の段階を経て作成されているとすれば、見出しは一応整列するかも知れませんが、それ以上の構造は全く明示できないのです。明示というのは、DTD のコメントや IGNORE 区間に記述されているということではなく、パーザに対して有意味な宣言として認識されるということです) -->だから ISO/IEC 15445 は駄目なのである(12)で、野崎さんの
もっと極端に言えば、という問いに、<div class="h1">これは見出しです</div>のような記述だって valid です。DTD 的に問題のない記述だから批判できませんか?「不思議マークアップをするな」と一蹴すべきですと答えた方の言葉とは思えませんが。
見出しの出現順についても、実際に明示されているわけではありません
というのは、結局見出しの順に関する制約が XHTML 1.1 と同一である、ということを述べているのです。ISO-HTML では見出しの出現順がデフォルトで検証できる、というのであれば、それは XHTML 1.1 にはない利点かも知れませんが、実際にはそんなこともない、と言っているのです。
ISO-HTML にも XHTML 1.1 にも見出しの検証を行う機構はありません。だから出鱈目な順で見出しを書いてよい、ということではなく、事実としてそうだと言っているのです。ISO-HTML では、特殊な機構が採用されている訳でもないのに、単に章の明示が禁止されています。章の明示を禁止することには何か意味があるのでしょうか。そういうことを問うているのですが。
出来上がった文書に構造を明示することと、DTD に示唆を明示することは関係ありません。(中略)
どうも論点がズレていませんか。ISO-HTML の仕様の是非を論じているのに、なんで出来上がったデータの話をしているのでしょう。
ISO-HTML の仕様では DTD の制約上、できあがる文書(データ)の構造が特殊なものになるから問題にしているのです。それが一番重要な問題だと思うのですが。
もっとも、私個人としては、データには期待してないけど、処理機構には期待するところが大きいです。
(中略)ISO-HTML に限っていうなら、どちらかを選ぶ必要なんてありません。だって、ISO-HTML に準拠して書かれた文書なら、機械的に xHTML に変換出来ますから。石川さんの言う、DIV 要素による文書構造の明示までも含めて。
ですから、そんな非標準的な処理機構を期待してはいけないと言っているのです。機械的に処理できればよいと言うものではありません。それでは「b を strong に置換すれば、論理的なマーク付けとして処理できる」などというのと同レベルです。
データは公開された状態が全てです。処理後の文書を公開する、というのならまだ解るのですが、公開したものに対してデータとしての質を変えてしまうような処理を期待してはいけません。ISO-HTML を利用するのであれば、見出しの階層構造とは完全に無縁な文書を作成するしかないのです。
そういう文書を作成することを推奨する意味が、何かあるのでしょうか。
表中における空セルは、空白である事に意味があります。そのため、空白を括るという概念が存在します。空要素のように括るものがない、とは意味合いからして違います。
また、本来の意味では空白ではなく、ZERO なり、SPACE なり、「記載省略」や「該当ナシ」(若しくは「'Nuff Said!」とか)といった文言が入るべきところを省略しているものです。
空要素
というのは img 要素などを指しているものと思いますが、恐らく img 要素などが空要素である理由を誤解しているのではないでしょうか。img 要素にも当然括られるべき内容があります。img 要素型や hr 要素型などではその内容が文字データでないから、内容が空であるものとして扱っているのです。
例1の文書をマーク付けすると、例2のようになります。ここで、画像データは直接テキストとして表現できないため、内容を省略して表現するのです。例2のようなマーク付けにおいて、img の終了タグを省略しなければならない理由が何かありますか。
# img が空要素になったのは一部ブラウザの独自拡張に由来するものですが、別に画像を空要素として表現するということ自体はおかしなことではありません。
注意:以下の記事はかなり適当です。信用は自己責任で(?)
XML 1.1 の最初の草案を元にでっちあげたもの。XML 1.0 の SGML 宣言からの差分のみ。バージョン、そのバージョンの仕様書での定義、対応する SGML 宣言、という順に列挙した。
まず、SGML 文字。
[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD]
| [#x10000-#x10FFFF]CHARSET
DESCSET
0 9 UNUSED
9 2 9 -- #x9-#xA --
11 2 UNUSED
13 1 13 -- #xD --
14 18 UNUSED
32 95 32 -- #x20-#x7E --
127 1 UNUSED -- UNUSED らしい --
128 32 UNUSED -- 同上 --
160 55136 160 -- #xA0-#xD7FF --
55296 2048 UNUSED
57344 8190 57344 -- #xE000-#xFFFD --
65534 2 UNUSED
65536 1048576 65536 -- #x10000-#x10FFFF --[2] Char ::= [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]CHARSET
DESCSET
0 1 UNUSED
1 126 1 -- #x1-#x7E --
127 1 UNUSED -- 多分 UNUSED --
128 32 UNUSED -- 同上 --
160 55136 160 -- #xA0-#xD7FF --
55296 2048 UNUSED
57344 8190 57344 -- #xE000-#xFFFD --
65534 2 UNUSED
65536 1048576 65536 -- #x10000-#x10FFFF --XML 1.0 の SGML 宣言を見ると、勧告を読む限り使えるような気のする #x7F-#x9F が UNUSED になっている。理由はよく解らないのだが、恐らく XML 1.1 でも同様なのだと思われる。#x1-#xD7FF は全部使えるはずなのだが。
次、機能文字。
[3] S ::= (#x20 | #x9 | #xD | #xA)+SYNTAX
FUNCTION
RE 13
RS 10
SPACE 32
TAB SEPCHAR 9[3] S ::= (#x9 | #x20 | #xA | #xD | #x85 | #x2028)+SYNTAX
FUNCTION
RE 13
RS 10
SPACE 32
TAB SEPCHAR 9
NEWLINE SEPCHAR 133 -- newline (#x85) --
ULS SEPCHAR 8232 -- Unicode line separator (#x2028) --空白文字に #x85 と #x2028 が追加される(名前は適当)。この辺りは問題ないはず。
最後、名前開始文字と名前文字。
[4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':'
| CombiningChar | ExtenderSYNTAX
NAMING
LCNMSTRT ""
UCNMSTRT ""
NAMESTRT
58 95 192-214 216-246 248-305 308-318 321-328
330-382 384-451 461-496 500-501 506-535 592-680
699-705 902 904-906 908 910-929 931-974 976-982
986 988 990 992 994-1011 1025-1036 1038-1103
1105-1116 1118-1153 1168-1220 1223-1224
1227-1228 1232-1259 1262-1269 1272-1273
1329-1366 1369 1377-1414 1488-1514 1520-1522
1569-1594 1601-1610 1649-1719 1722-1726
1728-1742 1744-1747 1749 1765-1766 2309-2361
2365 2392-2401 2437-2444 2447-2448 2451-2472
2474-2480 2482 2486-2489 2524-2525 2527-2529
2544-2545 2565-2570 2575-2576 2579-2600
2602-2608 2610-2611 2613-2614 2616-2617
2649-2652 2654 2674-2676 2693-2699 2701
2703-2705 2707-2728 2730-2736 2738-2739
2741-2745 2749 2784 2821-2828 2831-2832
2835-2856 2858-2864 2866-2867 2870-2873 2877
2908-2909 2911-2913 2949-2954 2958-2960
2962-2965 2969-2970 2972 2974-2975 2979-2980
2984-2986 2990-2997 2999-3001 3077-3084
3086-3088 3090-3112 3114-3123 3125-3129
3168-3169 3205-3212 3214-3216 3218-3240
3242-3251 3253-3257 3294 3296-3297 3333-3340
3342-3344 3346-3368 3370-3385 3424-3425
3585-3630 3632 3634-3635 3648-3653 3713-3714
3716 3719-3720 3722 3725 3732-3735 3737-3743
3745-3747 3749 3751 3754-3755 3757-3758 3760
3762-3763 3773 3776-3780 3904-3911 3913-3945
4256-4293 4304-4342 4352 4354-4355 4357-4359
4361 4363-4364 4366-4370 4412 4414 4416 4428
4430 4432 4436-4437 4441 4447-4449 4451 4453
4455 4457 4461-4462 4466-4467 4469 4510 4520
4523 4526-4527 4535-4536 4538 4540-4546 4587
4592 4601 7680-7835 7840-7929 7936-7957
7960-7965 7968-8005 8008-8013 8016-8023 8025
8027 8029 8031-8061 8064-8116 8118-8124 8126
8130-8132 8134-8140 8144-8147 8150-8155
8160-8172 8178-8180 8182-8188 8486 8490-8491
8494 8576-8578 12295 12321-12329 12353-12436
12449-12538 12549-12588 19968-40869 44032-55203
LCNMCHAR ""
UCNMCHAR ""
NAMECHAR
45-46 183 720-721 768-837 864-865 903 1155-1158
1425-1441 1443-1465 1467-1469 1471 1473-1474
1476 1600 1611-1618 1632-1641 1648 1750-1764
1767-1768 1770-1773 1776-1785 2305-2307 2364
2366-2381 2385-2388 2402-2403 2406-2415
2433-2435 2492 2494-2500 2503-2504 2507-2509
2519 2530-2531 2534-2543 2562 2620 2622-2626
2631-2632 2635-2637 2662-2673 2689-2691 2748
2750-2757 2759-2761 2763-2765 2790-2799
2817-2819 2876 2878-2883 2887-2888 2891-2893
2902-2903 2918-2927 2946-2947 3006-3010
3014-3016 3018-3021 3031 3047-3055 3073-3075
3134-3140 3142-3144 3146-3149 3157-3158
3174-3183 3202-3203 3262-3268 3270-3272
3274-3277 3285-3286 3302-3311 3330-3331
3390-3395 3398-3400 3402-3405 3415 3430-3439
3633 3636-3642 3654-3662 3664-3673 3761
3764-3769 3771-3772 3782 3784-3789 3792-3801
3864-3865 3872-3881 3893 3895 3897 3902-3903
3953-3972 3974-3979 3984-3989 3991 3993-4013
4017-4023 4025 8400-8412 8417 12293 12330-12335
12337-12341 12441-12442 12445-12446 12540-12542[4] NameStartChar ::= ":" | [A-Z] | "_" | [a-z] | [#xC0-#x02FF]
| [#x0370-#x037D] | [#x037F-#x2027] | [#x202A-#x218F]
| [#x2800-#xD7FF] | [#xE000-#xFDCF] | [#xFDE0-#xFFEF]
| [#x10000-#x10FFFF]
[4a] NameChar ::= NameStartChar | "-" | "." | [0-9] | #xB7
| [#x0300-#x036F]SYNTAX
NAMING
LCNMSTRT ""
UCNMSTRT ""
NAMESTRT
58 95 192-767 880-893 895-8231 8234-8591
10240-55295 57344-64975 64992-65519
-- 65536-1114111 (#x10000-#x10FFFF) は駄目? --
LCNMCHAR ""
UCNMCHAR ""
NAMECHAR
45-46 183 768-879XML 1.1 は非常に簡潔(要は何でも通る)。使えるはずの #x10000-#x10FFFF を含めるとエラーになるのだが、やっぱりよく解らない。ベースセットが違うのだろうか(追記:パーザ側の問題かも知れません。Next:2002年03月24日:"W3C HTML Validation Service メモ"を参照して下さい)。
おまけ、追加要件。
SEEALSO "ISO 8879//NOTATION Extensible Markup Language (XML) 1.0//EN"SEEALSO "ISO 8879//NOTATION Extensible Markup Language (XML) 1.1//EN"多分こんな感じになると思われ。バージョンの数字を変えただけ。
以下参考。
文書の初めに次のような宣言を書けば、XML 1.1 草案での整形式/妥当性検証が行えるはず。多分。…本当は、現状では SEEALSO NONE か SEEALSO "ISO 8879//NOTATION Extensible Markup Language (XML) 1.0//EN" にしておくべきなのだが。
<!SGML xml11 SYSTEM "http://www.pcc.metro-u.ac.jp/%7Et0040238/dtd/xml11-wd1.sd""http://www.satoshii.org/dtd/xml-sd/WD20011213.sd" ><!SGML xml11 SYSTEM "http://www.pcc.metro-u.ac.jp/%7Et0040238/dtd/xml11-wd1-valid.sd""http://www.satoshii.org/dtd/xml-sd/WD20011213V.sd" ># なお W3C HTML Validation Service では、文書インスタンスに xmlns 属性が記述されているとエラーになる(本当に XML 文書と見なされてしまうため。XML では SGML 宣言を明示的に記述することはできない)。#FIXED での指定なら大丈夫なのだが。
span がないとインラインでの言語指定に困るような(謎)。しかし、毎度毎度 <span xml:lang="en">…</span> とやっていると、それはそれで微妙に馬鹿馬鹿しくなってきたりして。
<!ENTITY XHTML.version
"-//Mark no Tsukekata//DTD XHTML 1.1 plus language extensions//EN"
>
<!ENTITY % XHTML.xmlns "http://www.w3.org/1999/xhtml" >
<!ENTITY % XHTML.xmlns.attrib
"xmlns %URI.datatype; #FIXED '%XHTML.xmlns;'
xmlns:l %URI.datatype; #FIXED 'http://www.pcc.metro-u.ac.jp/~t0040238/lang'"
>
<!ENTITY % Inline.extra "| l:en" >
<!ENTITY % xhtml11.dtd
PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" >
%xhtml11.dtd;
<!ELEMENT l:en ( #PCDATA | %Inline.mix; )* >
<!ATTLIST l:en
xml:lang %LanguageCode.datatype; #FIXED 'en'
>せめてこんな感じにできないものか。
できないものかって、できるんだけども。実装がなあ。でも別にやってもいいよなあ。このくらい。というか、このくらいやらずして何が extensible か。
…しかし、上の段落のソースはやはり <span xml:lang="en">extensible</span> なのだった。お後が宜しいようで。
当時の僕はいわゆる PSVI の弊害とかについて無頓着だったのでこんなことを書いていますが、勿論今はこんなことを考えちゃいません。
属性リスト宣言の省略時値の構文は、次のようになっている。
省略時値 = ((rni, 'FIXED', ps+)?, 属性値指定) |
(rni, ('REQUIRED'|'CURRENT'|'CONREF'|'IMPLIED'))XML では CURRENT / CONREF は指定できないし、ps+ の部分が S になっているので、FIXED キーワードと属性値指定の間には空白文字が必須になっているが、他は概ね同様である。
属性値指定というのは、開始タグに属性を記述するときの等号の右側の部分と同じものである。つまり name=value の時の'value' や name="rcdata" の時の '"rcdata"' と同様の構文となる。例えば、SHORTTAG YES な SGML では #FIXED value といった記述も可能である。
また、属性値リテラルの内容は RCDATA であるから、引用符で括られた内容では一般実体参照や文字参照は認知するが、パラメタ実体参照は認知しない。つまり、#FIXED 'one & only' という記述の場合には、& は一般実体参照と見なされるが、#FIXED '%XHTML.xmlns;' という記述の場合には、%XHTML.xmlns; はパラメタ実体参照ではなくただの CDATA として扱われる。
…ということで、次のような宣言をしてしまうと、意図に反した解析が行われてしまうので注意すること。
<!ENTITY XHTML.version
"-//Mark no Tsukekata//DTD XHTML 1.1 plus language extensions//EN"
>
<!ENTITY % XHTML.xmlns.attrib
"xmlns %URI.datatype; #FIXED '%XHTML.xmlns;'
xmlns:l %URI.datatype; #FIXED 'http://www.pcc.metro-u.ac.jp/~t0040238/lang'"
>
<!ENTITY % Inline.extra "| l:en" >
<!ENTITY % xhtml11.dtd
PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" >
%xhtml11.dtd;
<!ELEMENT l:en ( #PCDATA | %Inline.mix; )* >
<!ATTLIST l:en
xml:lang %LanguageCode.datatype; #FIXED 'en'
>この場合、<!ATTLIST %span.qname; %core.attrib; … > のように %core.attrib; を介して xmlns 属性を宣言している要素型では xmlns="http://www.w3.org/1999/xhtml" であるが、<!ATTLIST %html.qname; %XHTML.xmlns.attrib; … > のように直接 %XHTML.xmlns.attrib; によって xmlns 属性を宣言している要素型では xmlns="%XHTML.xmlns;" ということになってしまうのである。
# パーザのバグかと思ってしまった。七度尋ねて人を疑え。
SP - XML support を読んでいて、There is no support for characters outside the basic multilingual plane (ie those with scalar values greater than U+FFFF).
という記述を見付けた。#x10000-#x10FFFF を名前文字に含めるとエラーになるのは、このせいかも知れない。
ついでに、気付いたこと。明記はされていないんだけど、XML を検証する場合、どうも文書型宣言の外部識別子によって検証の種類を変えるらしい。SYSTEM なら整形式検証のみで、PUBLIC なら妥当性も検証する模様。何でそういう仕様なのかは不明だが。
PRE 中の
i<65535に「不正なSTAGOです」と注意文が出てどうしたのかと思った。
Digit は名前文字ではあっても名前開始文字ではないので、i<65535 は valid です。
MacIE 5.x は <a id="latest"</> を正しく処理できるんだけど、WinIE はどうなのだろう。まあ MacIE 5.x の挙動もエラー処理の結果ってことだろうけど、tagc の省略と空の終了タグ(空の開始タグは無理)は正しく処理できている模様。
でも <script></> はやっぱり無理か。XHTML での <script/> にも対応していないし。
逆に、Mozilla は <script/> には対応しているっぽい。でも、何故かソースを表示させると <script/></script> となっている。もしかして、普段も書いてある通りのソースを表示している訳ではないのだろうか。
上の記事を書いていてふと思ったのだが、CDATA の要素で NET を使うことはできるのだろうか。
要素の内容が、その要素の宣言内容に従って置換可能文字データ又は文字データとなっている場合、その内容は、その文脈依存区切り子 etago (正当な終了タグとなっていなくてもよい。)又は正当な net によってだけ終わる。ただし、その内容が混合内容であるとしたら誤りとなってしまう終了は、誤りとする。
使えるらしい。しかも、CDATA の要素では内容に </ という文字列が出現した時点で終了するというような勘違いをしていたのだが、きちんと etago として認知した場合にしか終了しないようだ。つまり、HTML 4.01 などでの <script type="text/javascript"> … '<'+element+attsStr+'>'+content+'</'+element+'>' … </script> のような記述は妥当であり、構文上は特に '<\/' とする必要はないということになる(' は名前開始文字ではないから)。
# <script type="text/javascript"> … '<p>'+content+'</p>' … </script> のようなものは不正です。念のため。
The use of "compatibility characters", as defined in section 6.8 of [Unicode] (see also D21 in section 3.6 of [Unicode3]), is discouraged.
全角英数字(JIS X 0208 のラテン文字用図形文字)及び半角片仮名(JIS X 0201 の片仮名用図形文字)については、その使用を避ける。XMLの規定は、Unicode 2.0 の互換性文字の使用を避けることを薦めている。
文字参照(番号による文字指定)又は実体参照によって、全角英数字又は半角片仮名を表現することができる。この方法を用いれば、どんな符号化方式でも、全角英数字又は半角片仮名を表現できる。
ということで、XML では(いわゆる)全角英数字と半角片仮名の使用は discouraged
とされているんだけど、あんまり知られていないような。
文字としての定義では、例えば "Ａ"(全角:#xFF21) と "A"(半角:#x41) の字形は同一ということになっています。前者が全角で表示されるかどうかは(本来)フォント依存ですし、逆に言えば後者を全角で表示するフォントだって有り得るわけです。従って、表示を気にして両者を使い分ける意味は(原理的には)全くありません。
同じ字形の文字なら、一つのコードで表される方が好ましいのは言うまでもないと思います。現に、Google はこういった重複する文字を同一視するための処理を行っていますが、このような処理は本来は無用なものです。こういう無用な処理を減らすためにも、できるだけ全角英数字や半角片仮名の使用は避けることが望ましいでしょう。
XML 1.0 では、前記の「非推奨の文字」は名前文字には含まれていません。つまり、これらの文字を要素名や属性名として利用することは文法違反になります(例えば <Ａ>…</Ａ> は not well-formed)。
ところが、XML 1.1 (の現時点の草案) ではこれらの文字も名前開始文字に含まれているんですよね。例えば全角英数や半角片仮名は、前記の SGML 宣言で言えば SYNTAX NAMING NAMESTRT 64992-65519 に含まれています。従って、<Ａ>…</Ａ> のような記述も XML 1.1 では well-formed です。
とは言え、これらの文字の使用が非推奨であるということには変わりありませんし、XML 1.0 向けのパーザではこれをエラーとして扱ってしまうでしょうから、今後もやはり好きこのんで使うべきではないでしょう。
何故非推奨の文字をわざわざ名前文字に使えるようにしたのか、ということについては、[XML MOJI 01172] Re: XML 1.1 Working Draft などが詳しいと思います。
補足。XML 1.0 でも、要素内容などにこういう文字を記述することは文法的には全く問題ありません。なので、文字参照にしなくとも、一応パーザにはねられたり
することはないはずです(文字参照の方がベターではありますが)。趣旨は「全角・半角に拘らないなら標準的な方を使うことが望ましい」ということなので(「全角カナ > 半角カナ(文字参照) > 半角カナ」というか)。
例えば「本来表示幅はフォント依存」とは言え、実際にはほとんどのフォントが半角カナを半角で表示します。なので、AA などに半角カナが使われている場合には、文字の示す内容よりも表示の方を重視する、というのもありなのではないかなー、とも思います(その場合にも文字参照にする方が好ましいのですが)。
このサイトでは、引用の際にも基本的に半角カナは全角カナに、全角英数は半角英数に変換しているのですが、AA やサイト名などにそういう文字が使われていると、やはり微妙に躊躇ってしまいます。現状そういう場合は元の文字のままで引用を行っています(文字参照にはしますが)。
# 更に言うと、実は Google などは文字参照を展開していません。なので、例えば "ｱｲｳｴｵ" と記述されている箇所は、"ｱｲｳｴｵ" を検索してもヒットしなかったりします。
# …とは言え、普通、文中で半角カナを使っているような語句は検索でヒットしなくても困らないよなあ…などとも思うわけで。だったら文字参照しても別にいいよなあ、と。でも、サイト名に半角カナを使っているような場合は…うーん…微妙。