ちなみにねー、去年の正月くらいだったか、初めて <p>…ここが段落だよ…</p>
という記述を見たときは、目が丸くなったもんです。「え? p に終了タグ?」と。「p = 段落の末尾に付ける」という、いわゆるお尻 p が唯一無二の p の書式だと信じていたもので。<br>…ここが改行されるよ…</br>
と書かれるくらいの奇妙さを感じたわけです。
あと、<header>
じゃなくて <head>
の方が普通なんじゃないだろうか、というのは当時も薄々感づいてはいたんですが。どっちでもよいものとばかり。Another HTML-lint に header 要素なんてもんは存在しない
と断言されたときはどうしようかと思いました。
… marquee と blink が入れ子になっているのにもそれなりの理由がありまして。僕は当時から IE ユーザだったので、はっきり言って「ネスケなんかどうでもいい」と思っていました。「ネスケって超使えねー。今日び marquee なんて i モードでも対応してるぜ」とすら思っていました(流石に口には出さなかったが)。それでもネスケユーザのことも考え、ネスケでは marquee の代わりに blink で表示されるようにしておこう、と慮って marquee と blink を入れ子にしていたのです。
ん? DOCTYPE? CSS? 当時そんな単語は知りませんでした。あーでも、CSS についてはねこめしにっきで触れられてたから、名前だけは知ってました。どういうものなのかは知らなかったんですが。
でも、table をレイアウトのために使ったり、blockquote をインデントのために使ったりしたことは一度もありませんでしたよ。これちょっと自慢。まあ、それほどのレイアウトをする知識がなかっただけなんですけどね。
Wayback Machine のキャッシュが消えていたので、ローカルに再公開。なお、これはエイプリルフールのジョークですが、述べられていることは全て事実です。
あと、これは http://www.pcc.metro-u.ac.jp/~t0040238/
の話ですので、誤解なきよう。学校の講義で習った知識で、その講義の課題として作ったサイトの後継がこれでした。ちなみに評価は 5 でした。笑い。
Namespaces in XML 1.1 及び Namespaces in XML 1.1 Requirements の最初の草案が公開されました。Namespaces in XML からの変更点は、xmlns:hoge
の形の属性の値として空文字列が認められる(xmlns:hoge=""
)ということのようです。なお、Namespaces in XML 1.1 は Namespaces in XML (1.0) のスーパーセットとして設計されることになっています。
<?xml version="1.1" ?>
<doc xmlns="foo">
<e>…</e>
<h:e>…</h:e>
</doc>
例えば、この文書では 'h' という名前空間接頭辞は宣言されていません。従って、h:e という要素の出現は不正なものと見なされます。
<?xml version="1.1" ?>
<doc xmlns="foo" xmlns:h="hoeee">
<e>…</e>
<h:e>…</h:e>
</doc>
一方、こちらは 'h' という接頭辞が宣言されているため、正しい記述と見なされます。
ここで、e 要素内では 'h' という接頭辞を持つ要素型が出現しないことになっている場合、e 要素内では xmlns:h="hoeee"
という宣言が無効化されている方が都合の良い場合があります。xmlns:h についての宣言がなされているままだと、e 要素内の各要素も自動的に xmlns:h="hoeee"
という宣言(ノード)を持つものと見なされてしまい、効率が悪くなってしまうためです。
そこで、XML 1.1 では次のような宣言が認められることになりました。
<?xml version="1.1" ?>
<doc xmlns="foo" xmlns:h="hoeee">
<e xmlns:h="">…</e>
<h:e>…</h:e>
</doc>
こうすることで、e 要素の中では 'h' という接頭辞についての宣言は無効化されます。上は正しい記述ですが、次の記述は不正です。
<?xml version="1.1" ?>
<doc xmlns="foo" xmlns:h="hoeee">
<e xmlns:h="">
<h:e0>…</h:e0>
</e>
<h:e>…</h:e>
</doc>
e 要素の中では 'h' に関する宣言がキャンセルされていますから、h:e0 という要素は出現できない訳です。なお、一旦キャンセルした宣言をもう一度宣言し直した場合は問題はありません。
<?xml version="1.1" ?>
<doc xmlns="foo" xmlns:h="hoeee">
<e xmlns:h="">
<e0 xmlns:h="hoeee">
<h:e0>…</h:e0>
</e0>
</e>
<h:e>…</h:e>
</doc>
ちなみに 'Namespaces in XML 1.1' というのは、'Namespace in XML' の 'version 1.1' ではなく 'XML 1.1' における 'Namespace' の意味です。つまり、XML 1.1 の文書では名前空間はこのようになります、というものなので、XML 宣言(のバージョン宣言)で version="1.0"
を宣言している文書は、この勧告(草案)の影響を受けることはありません。
typo がありましたが、xmlns=""
と xmlns:foo=""
はまったく別の意味を持ちます。前者は Namespace in XML でも許される構文で、名前空間を持たない要素型を表現するためのデフォルト名前空間宣言です。
例えば XHTML を拡張して embed 要素型を記述するような場合、embed は明確な(?) XML 名前空間を持たないので、<p> ... <embed xmlns="" ... /> ... </p>
というように記述することになるわけです。
まだちゃんと読んでいないんですが。用例はこんな感じだそうです。
<?xml version="1.0" encoding="ISO-8859-1"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xml:lang="en-US">
<paragraph>I don't speak Japanese.</paragraph>
<paragraph xml:lang="ja">Nihongo-ga wakarimasen.</paragraph>
で、本文とは余り関係ないのですが、Nihongo-ga wakarimasen.
が xml:lang="ja"
であるということにはちょっと注意して欲しいと思います。ある文がどの言語で記述されているかということは、表記されている文字がどのような文字かということとは関係がないのです。
以前、「和文に英文が混じるときには英文の前後に間を取るが、これは CSS で span:lang(en), em:lang(en), ... {margin:0 0.2em;}
などとすべきで、地の文に半角空白を記述すべきではない」という主張を見掛けたのですが、これは <p>日本放送協会を略して NHK と呼ぶ。</p>
などという文章には適応のしようがありません。
ということで、文中にアルファベットが出現する場合には、単語の切れ目を半角空白で示す、というのが自然な記述であるように思います。
division かと。
文中に div 以外の要素型に該当しないブロック要素があるとき、その要素を明示するために。
div が汎用のブロック要素型である、という立場からすれば、以下のいずれかになるかと。
(%Block.mix;)+
(#PCDATA | %Inline.mix;)*
EMPTY
(#PCDATA | %Flow.mix;)*
上に述べた div 要素型相当の要素のうち、範囲が異なり、かつネストするものがあるとき。
制作者が場合に応じて判断すべきでしょうが、章や節くらいは明示するのが望ましいと思います。
内容を (%Block.mix;)+
とする場合の例は、章や節の明示など。この文書のマーク付けそのものです。(#PCDATA | %Inline.mix;)*
は、例えば h7 に相当する要素の明示など。
EMPTY
は、例えば hr を論理要素化しての明示など。<hr/>
よりは <div class="分割点"/>
の方が論理的ではあると思います。これはまっとうな空要素です(# 僕は <div class="unitBottom"/>
も別におかしくないと思うんですが。恣意的なマーク付けとは言え、ああいうのは論理的な装飾だと思うし)。
(#PCDATA | %Flow.mix;)*
は、例えば現状の XHTML 1.1 の定義を変えずに p > ul のような構造を明示したい場合などに有り得ると思います。
<div class="para">
私の座右の銘は
<ul>
<li>strict に非ずんば HTML に非ず</li>
<li>valid に非ずんば SGML に非ず</li>
</ul>
です。
</div>
こういった場合。もっとも、これは余り好ましくないマーク付けだと思いますが。
同様に、span は文中に span 以外の要素型に該当しないインライン要素があるとき、その要素を明示するために用います。
span の内容は (#PCDATA | %Inline.mix;)*
または EMPTY
であるべきでしょう。前者には例えば <span xml:lang="en">…</span>
といった場合、後者には例えば <span class="略"/>
(引用文などの省略箇所を示す)といった場合が該当します。
span.略:first-child:before {
content:"(前略)";
}
span.略:last-child:before {
content:"(後略)";
}
span.略 {
content:"(中略)";
}
こんなのや、あるいは span.略:before {content:"<snip/>";}
といったスタイルシートを組み合わせたり。
# 他に、<span class="証明終わり"/>
なんて例もあります。「証明終わり」を示す記号や言葉は色々ありますから、これらの記号類はスタイルシートで統一して設定する方が良いこともあるでしょう。'□'や 'q.e.d.' などを content プロパティで挿入するわけです。
またちょっといじって(バージョンは面倒なので 1.1 を上書き)、フレームセットに対応しました。進歩したのか後退したのかよく解りませんが。
あと、公開識別子の所有者識別子を -//Mark no Tsukekata
から +//IDN math.oheya.to
に変更しました。変更しましたが、元のままでも特に問題はありません。システム識別子と一緒に変更するつもりだったのですが、すっかり忘れていたんです。
本当は以前から IDN 所有者識別子を使いたかったのですが、pcc.metro-u.ac.jp 時代にはこれができなかったもので。公開識別子には ~
も %
も認められていないため、http://www.pcc.metro-u.ac.jp/~t004023/
を所有者識別子にすることは不可能だったのです。移転に伴い晴れてこれが可能になりました。
なお、-//
が +//
になることにはそれなりの意味があります。前者は「恐らく一意の」識別子に過ぎませんが、後者は「確実に一意の」識別子となるのです(とは言っても実際には公開識別子なんて殆ど役に立たないんですが)。
ちなみに、旧来の SGML では +//…
で始まる所有者識別子は全て登録所有者識別子を表していましたが、Web SGML では(つまり XML でも) +//IDN …
で始まる所有者識別子は IDN 所有者識別子として別扱いされています。
所有者名にドメイン名が入っていれば、所有者を登録しなくとも一意性が保証できるので、登録所有者でなくとも +//
の識別子を用いることができるわけです。
公開識別子の %
云々については 2002-04-29 の IDN 所有者識別子(2) の訂正を参照して下さい。
スタイルシートを外したり、profile 属性を書いたり。後者は、某所で話題に出ていたので調べ直してみたのが切っ掛けです。こんなのでも良いのだと思います(しつこいけど多分ですが)。まあ、first-edition
とか last-modified
とかは DC.Date で事足りような気もするんですが、rev="made"
を書くのに躊躇わなくて済むのが個人的には大きいのです。
当時は文書の初版公開と最終公開を <meta name="first-edition" content="2003-11-11" /><meta name="last-modified" content="2003-11-11" />
などと記述していました。ちなみに、リソースのオリジナル URI も meta name="original-uri"
で表現していたのです。
Last Call です。順調に策定中。
XML 1.1 も Last Call です。なお、物議を醸していた SGML 文字の(追加)変更に関する記述はなくなっています。
一応これに併せて、XML 1.1 に対応する(と思われる) SGML 宣言も更新してみました。
取り敢えず公開しないで放置するよりはましだろうということで、メンテナンスの済んでいない文書も公開してありますが、向こう一週間くらいは URI が変更される可能性があります。ごめんなさい。
Layout table
レイアウトを行うために表でないものを table 要素としてマーク付けするというのなら、それは少なくとも http://www.w3.org/1999/xhtml
の table 要素ではないのだから、他の名前空間を宣言して欲しいと思うのですが、如何でしょうか。この方法なら恐らく実害も皆無でしょうし > W3C 御中
長らく批判を受けていた W3C 自身によるテーブルレイアウトですが、トップページについては 2002-12-04 のリニューアルによってめでたくも適切な修正がなされました。(参考: W3C Home Page Table-less Layout: HOWTO and FAQ)
ということは、 XHTML Primary の公開識別子を、
+//IDN purl.org/net/lena/
のようにしてしまっても良いものなのでしょうか。
末尾の /
は余分ですが、+//IDN purl.org/net/lena
なら問題ないはずです。IDN 所有者識別子に使える文字は最小データ、つまり半角英数と '()+,-./:=?
及び RS RE ですから(←間違いです。IDN 所有者識別子(2)を参照のこと)、スラッシュは大丈夫です。詳しくは ISO/IEC JTC1/SC34 N0029 の K.4.6 Internet domain names in public identifiers を参照のこと。
まあ、最小データ以外の文字を使うのは明確な文法違反ですが、XML は FORMAL NO
なので必ずしも FPI (公的公開識別子)を使わねばならない訳ではないんですけどね。実際 XHTML でも -//W3C//NOTATIONS XHTML Notations 1.0//EN
なんて公開識別子が使われていますし (NOTATIONS
という公開文種別は存在しないので、この公開識別子は公的ではない)。
この辺りは最早趣味の世界という気がひしひしとします(笑)。
当時追記したつもりで書いてなかったみたいですが、その他に Modularization of XHTML の Conformance Definition 3.6. Naming Rules では XHTML Host Language document types の FPI を -//
で開始するように求めているので、厳密にこの勧告に適合するためには IDN 所有者識別子を用いることはできません。
この辺りのことについて、かつて www-html@w3.org 辺りで「何で未登録所有者識別子にこだわるの?」みたいな POST があったと記憶しているのですが、発見できませんでした。自分で投げようと思って忘れたとかではなかった気がするんだけどなあ。
という記述がありましたが、これは誤りでした。NOTATIONS
という公開文種別は存在しないので、この公開識別子は公的ではない
JIS X 4151-1992 の 9.2.2.1 には次の記述があります。
公開文種別の名前は、その公開文がどの SGML 構成要素を収めたものかを示す次の(1)〜(13)のいずれかでなければならない。
しかし、この記述は附属書 K の K.3.1 で次の通り変更されています。
10.2.2.1 (JIS X 4151においては、9.2.2.1) の文 "名前は…でなければならない" を "名前は…であることが望ましい" に置換する。
したがって -//W3C//NOTATIONS XHTML Notations 1.0//EN
は正しい公的公開識別子です。
前記で最小データ := 半角英数
と書きましたが、ふと思い付いて XML 1.0 勧告の公開識別子の定義を参照してみると、公開識別子に使える文字は '()+,-./:=?
RS RE#x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%]
となっていました。%
や ;!*#@$_
も使えることになっているみたいです。
で、怪訝に思って Web SGML の定義を読み直してみると、こんなことが書いてありました。
Semicolon, exclamation point, asterisk, number sign, commercial at sign, dollar sign, underscore, and percent sign are members of the abstract character class special
, which is usable in minimum data.
最小データそのものの定義は変更されていないものの、special クラスは '()+,-./:=?
から -'()+,./:=?;!*#@$_%
に拡張されていたようです。
つまり、実は +//IDN www.pcc.metro-u.ac.jp/%7Et0040238//DTD HTML for Geociteies//EN
という公開識別子も XML / Web SGML 的には問題なかったんですね。W3C の Validator で引っ掛かっていたので駄目なんだろうと思っていました。
ちなみに、Validator で引っ掛かっていたのは SGML 宣言本体の公開識別子に %
を含めていたのが原因のようです。もっとも、この記述も恐らく問題ないはずなので、パーザ側のバグのような気がしますが…。
# special クラスの拡張は Web SGML でしか利用できません。従って、SGML 宣言で "ISO 8879:1986 (WWW)"
を宣言した後でなければ、これらの(SGML 規格本体では禁じられている)文字を利用することはできないと考えることもできるのですが、そもそも SGML 宣言本体を外部識別子で参照するということ自体 Web SGML の拡張なので、前述のような仕様は不合理的な気がします。
ええと、NOTATIONS
は公開文種別もどきですが、NOTATION
は歴とした公開文種別ですので、誤解なきよう。記法を識別するための公開文種別が NOTATION
で、その記法宣言だけを纏めたモジュールだから ENTITIES
でも ELEMENTS
でも DTD
でもなく NOTATIONS
という文種別を付けたのでしょう。
で、xhtml-notations-1.mod の記法宣言がどんな記法を参照しているのか、ということですが、これは各宣言の前に付されている注釈の通りです。例えば、w3c-xml
という記法は下記のように宣言されています。
<!-- W3C XML 1.0 Recommendation -->
<!NOTATION w3c-xml
PUBLIC "ISO 8879//NOTATION Extensible Markup Language (XML) 1.0//EN" >
w3c-xml
という記法名は、注釈の通り XML 1.0 の記法を示すものです。記法宣言の外部識別子の役割は「その記法の処理に必要なアプリケーションを識別すること」ですから、ISO 8879//NOTATION Extensible Markup Language (XML) 1.0//EN
という公開識別子に対応しているパーザは、w3c-xml
という記法名を見付ければ XML パーザを起動することになる訳です。
しかし、個々のユーザの環境でそのアプリケーションがどんなパス(システム識別子)で示されているかなんてことは不明ですから、XHTML 1.1 のように非ローカルな環境で使われる DTD では、システム識別子は省略するのが普通です。
ウェブブラウザが「不明なファイルタイプです。プラグインを指定して下さい」といったダイアログを出すことがありますが、ここではファイルタイプに相当するのが「記法を示す公開識別子」で、実際に使用するプラグインに相当するのが「アプリケーションを示すシステム識別子」です。
プラグインを設定するのと同様に、XHTML 1.1 の記法を実際に(ユーザサイドで)利用するためには、公開識別子に対するシステム識別子をユーザ(またはパーザ)自身が設定しなければなりません。例えば SGML パーザの場合には、カタログに下記のような記述を追加します。
OVERRIDE YES
PUBLIC "ISO 8879//NOTATION Extensible Markup Language (XML) 1.0//EN" "xml/xml_parser"
こうすることによって、w3c-xml という記法名から xml_parser というアプリケーションを起動することができるようになる訳です。
なお、ローカル環境では特定の記法(ファイルタイプ)に対して起動するアプリケーションは具体的に決められていることが普通ですから、こういう場合には直接システム識別子でアプリケーションのパスを指定します。例えば、ローカルでは上記の宣言はこんな風に書き換えられます。
<!NOTATION w3c-xml
SYSTEM "file:///HD1/applications/xml/xml_parser" >
ちなみに、公開識別子とシステム識別子を同時に指定することもできます。
<!NOTATION w3c-xml
PUBLIC "ISO 8879//NOTATION Extensible Markup Language (XML) 1.0//EN"
"file:///HD1/applications/xml/xml_parser" >
これらの宣言では、システム識別子から直接アプリケーションの指定を行っている訳です。逆に、こういう宣言はフォルダの構成が異なる環境では意味を持ちませんから、前述の通り非ローカル環境で使用される DTD でこのような宣言が用いられることはないのです。
# まあ、これらの記法(名)は実際には DTD でも使用されていませんから、XHTML 1.1 の文書を作成する際にはほとんど無関係なのですが。敢えて XHTML 1.1 適合文書での利用法を挙げれば、処理命令のターゲットに使用することはできます(というかこれが唯一無二の利用法)。Geo-HTML 1.1 で xhtml-notations-1.mod を INCLUDE
したのも、一応これが理由だったりする訳で。
# なお、[82] NotationDecl ::= '<!NOTATION' S Name S (ExternalID | PublicID) S? '>'
の "ExternalID" が指すのは "PUBLIC 公開識別子 システム識別子"
または "SYSTEM システム識別子"
であり、"PublicID" が指すのは "PUBLIC 公開識別子"
ですから、記法宣言に対してもシステム識別子を記述することはできます(というか、他の宣言と比べると「例外的にシステム識別子を省略できる」ということですね)。
と、書いていますが、SGML の実装に関しては本で囓った程度なので、本当にこういう実装が一般的だったのかどうかは定かでないです。(今にして思うと)
SVG 1.1 / Mobile の勧告候補です。具体的な DTD やモジュール群も公開されました。ちなみに、svg 要素に xmlns:xlink 属性を記述できないという例の errata も修正されています。
…ところで、end of Apr 2002
になりましたけど、XHTML 2.0 草案は?
"SVG" は SVG 1.1 で、"basic" / "Tiny" はそれぞれ SVG 1.1 Basic / SVG 1.1 Tiny で取り込まれるモジュールであることを示しています。
以下、おまけ。
こんなものが! 何か、ある意味 HTML 3.0 の後継っぽいような?
ざっと目を通しただけだが、これは面白い。というか、ネタにしようと思っていたことが尽くまとめられてしまっているような。
システム識別子のベース URI を設定するパラメタ実体 (.sysid.base
) なんてものが登場していたり、色々と面白い機構が山盛。DTD の限界に挑んでいるかのようなギミックの集大成とすら感じられる(言い過ぎ)。
ちなみに、An XHTML + MathML + SVG Profile (application/xhtml+xml) の方はきちんと XHTML 1.1 plus MathML 2.0 plus SVG 1.1 を使って書かれていたりする。また律儀というか何というか。
しかもわざわざ XHTML 1.1 plus MathML 2.0 plus SVG 1.1 を使っておいて、MATHML.module
と SVG.module
は IGNORE
という辺り、狙ってやっているとしか :-)
# あ、W3C のトップから辿れないなと思っていたら、今更新された。しかし、今日(もとい昨日)は草案ラッシュだな…。XSLT 2.0 とか XPath 2.0 とか XQuery 1.0 とか Charmod 1.0 etc. の草案も新しくなっている。