XHTML $B$N0LCV$E$1(B (Re: XHTML $B$NBP1~>u67$K$D$$$F(B)

[Masayasu Ishikawa]

ブラウザの話じゃなくなってきたので authoring の方にでも移りましょう。

島さん>
>最近xhtmlについて勉強し始めたばかりなのですが、
>xhtmlの位置づけがはっきりしなくて困っています。
>
>htmlはプレーンテキストより便利（リンクを張ったり）な言語ですし、
>xmlはDTDを自分で定義できて、業界統一による巨大データベース的意味合いが
>大きいと思っています。

良く言えばその両方のメリットを享受できるのが XHTML ではないかと。
一口に XHTML といってもいろいろありますのでそのどれにメリットを
感じるかは人それぞれだとは思いますが。とりあえず手近なところで
XHTML 1.0 については、"1. What is XHTML?" [1] のところに XHTML
にすると何が嬉しいか書いてありますのでそれらにメリットを感じる
のなら使ってみればいいし、ピンと来なければ当面手を出さないでおく
のもまぁアリかと。Media type が 'text/html' に縛られてるうちは
少なくともブラウザ上での表示、という側面ではあんまり大層なことは
できないのも事実ではありますし。

>しかしxhtmlは・・・。
>将来w3cのxhtmlの勧告から
>フレームが外されるそうですし、

それはある意味正しくある意味間違ってます。

>ウェブページとしてはhtml4.0くらいで十分だと思うし、

…という人のための XHTML 1.0。

>xhtmlは
>xmlのようにxsltやxslを使ってデータを加工して表示するような
>事も出来ないし。（って現行のブラウザーでは表示できないみたいだし、
>表示できる*もの*が有るのか解りませんが。）

別に XHTML といえど syntax 的にはただの XML ですから XML に対して
できることは XHTML にもできますが。最近の IE や Mozilla、Netscape 6
あたりは XSLT プロセッサを内蔵してますし。

>xhtmlに関する皆さんのご見解をお聞かせ願えれば幸いです。

[1] http://www.w3.org/TR/xhtml1/#xhtml

--
Masayasu Ishikawa

# 悪く言えば HTML と XML のイヤなところを一挙に味わえる最悪のフォーマット ;-)

[ka...@sra-tohoku.co.jp]

かべ＠ＳＲＡ東北

>> >xhtmlに関する皆さんのご見解をお聞かせ願えれば幸いです。

・人間がタグ直打ちするのにはまったく向いていない。
・どうしても環境を XML に統一しなきゃヤダという人向け。
・拡張性は、単にブラウザに食わせるHTMLでは大した問題にならない。
(どっちにしたってどこかでXML→HTMLコンバータが必要になるから)

私見ですが SGML てのは、地の文の中にタグがちらほらとちりばめられている
のが本来の姿で、昨今のHTMLで良くみかける、タグの海の中に地の文が
ちらほらとあるのは異常な状態です。
XMLはこれをさらに助長しているような。
(Semantic Webもタグの海を奨励しているので好きではない)

SGML→HTMLの段階で、「人間に優しい」(けど機械にはちょっとつらい)機能が
大分削られていますが、 XML では「閉じタグ省略ダメ」という
タグのバイト数を増やすだけの、機械には優しいけど人間にはキビシイ規則
が強制されて、手でのタグ打ちは現実的でなくなりつつあります。
＃XHTMLならともかく一般のメタデータ系のXMLは手で打つ気がしないぞ
------------------------------------------------------------------------------
かべ@sra-tohoku.co.jp ＶＥＧＡ Ｓｙｓｔｅｍｓ MCMXCI
「自分はレーサーだっていうのかい？ たいしたことないじゃないか。」
------------------------------------------------------------------------------

[Shinji KONO]

河野 真治@琉球大情報工学です。

SGML 系の良さは、本当は、「読める」ところだったのにね。
Windows な連中が、そういうのを破壊してしまったのか...

In article <a39too$f5n$1...@yagi.ecei.tohoku.ac.jp>,
ka...@sra-tohoku.co.jp writes

>SGML→HTMLの段階で、「人間に優しい」(けど機械にはちょっとつらい)機能が
>大分削られていますが、 XML では「閉じタグ省略ダメ」という
>タグのバイト数を増やすだけの、機械には優しいけど人間にはキビシイ規則
>が強制されて、手でのタグ打ちは現実的でなくなりつつあります。

そうねぇ。きっと、「Readable XHTML」とか、そんなのが出て来るんじゃない?
まさか、構造化 XHTML とは呼ばないだろうけど...

よってたかって、PL/1 みたいなのとか ADA みたいなのを作っちゃって、
結局、「つかえん!」ってのは、良くある話。

HTML は、Alogol 68 から、単純化した Pascal みたいな感じで、
使いやすかったんですけどね。

人間に見にくいものは、機械にも見にくいってのに、(再度)気づくのは
いつのことか?

---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)

[Masanori HATA]

畑です。

"Masayasu Ishikawa" <mim...@sfc.keio.ac.jp> wrote in message news:a39mjs$7va$1...@news.sfc.keio.ac.jp...
> >将来w3cのxhtmlの勧告から
> >フレームが外されるそうですし、
>
> それはある意味正しくある意味間違ってます。

すみません、亀レスになってしまいましたが、fj.sys.ibmpcの方から
こちらに振った僕のリプライのせいで誤解を招いたのかも知れません。

モジュール化の結果、XHTML1.1では、XHTML1.0 Strict的なモジュール
群を必須のコア・モジュールとし、それ以外のものは拡張モジュール
として定義されるということですよね。（＞石川センセイ）

つまり、コアモジュールというのは吉○屋の牛丼で、フレームは、牛
丼に対するオプションのお新香なわけで、お新香が吉○屋（W3C）の
メニューから消えるということを意味するのではなくて、従来は、紅
生姜みたいな扱いだったフレームモジュールが、将来的にはお新香の
ように追加オプションとしてのメニューに変更になるよ、ということ
ではないかと。

--
Masanori HATA / "Good Thoughts, Good Words, Good Deeds"

[Masanori HATA]

畑です。

<ka...@sra-tohoku.co.jp> wrote in message news:a39too$f5n$1...@yagi.ecei.tohoku.ac.jp...

> かべ＠ＳＲＡ東北
>
> >> >xhtmlに関する皆さんのご見解をお聞かせ願えれば幸いです。
>
> ・人間がタグ直打ちするのにはまったく向いていない。
> ・どうしても環境を XML に統一しなきゃヤダという人向け。
> ・拡張性は、単にブラウザに食わせるHTMLでは大した問題にならない。
> (どっちにしたってどこかでXML→HTMLコンバータが必要になるから)
>
> 私見ですが SGML てのは、地の文の中にタグがちらほらとちりばめられている
> のが本来の姿で、昨今のHTMLで良くみかける、タグの海の中に地の文が
> ちらほらとあるのは異常な状態です。
> XMLはこれをさらに助長しているような。
>

> SGML→HTMLの段階で、「人間に優しい」(けど機械にはちょっとつらい)機能が
> 大分削られていますが、 XML では「閉じタグ省略ダメ」という
> タグのバイト数を増やすだけの、機械には優しいけど人間にはキビシイ規則
> が強制されて、手でのタグ打ちは現実的でなくなりつつあります。
> ＃XHTMLならともかく一般のメタデータ系のXMLは手で打つ気がしないぞ

うーん、僕の場合、実際にXHTML1.1化をやってみて、意外と、
HTML4.01 Strictとあんまし変わらんなあという感想でした。
もともと、過去にHTML4.01 Strictをやろうとした段階で、そ
れなりの労力を要しましたが、その時の経験があったために、
HTML4.01 Strict系で表現できる範囲内に収まるような文書を
最初から書く習慣がついたからかもしれません。

（不特定多数の）XHTMLなデータを閲覧する場合と、単に自分
で作成する場合では、事情が違ってくるような気がします。
自分で作成する場合は、タグを最小限に抑えればいいだけで
すから（or タグを最小限に抑えるような文章形態にする）。

# というわけで、XHTML1.1までに関しては、僕個人の場合、
# 「直打ちオッケー」という結論に達しています。

# XMLは今でもよーわからんです。(^^;

ただ、rubyタグに関しては、「地の文にタグをぶら下げる」
という感覚から逸脱しているとは思います。ルビはあくまで
もルビで、本文の飾りに過ぎないのに、rubyって、本文をぐ
しゃぐしゃにしないと成立しませんし……。dlタグっぽい方
式を採用しちゃったみたいで。

# むしろ、titleやaltみたいな、属性で指定する方が自然だ
# と思うのは僕だけでしょうか？
# ex. <ruby title="としのみやあいこ">敬宮愛子</ruby>

XMLはともかく、XHTMLというのは、HTMLをモジュール化した
かったということなのではないでしょうかね？
モジュール化に対応できないままだと、サードパーティーが
拡張タグをデファクト・スタンダード化する都度、W3Cの方
で追認の形で、W3C規格全体をバージョンアップして対応し
ていく必要に迫られてしまいますが、そういったことに振り
回されずに、HTMLのコアな部分をW3C純正な状態に保つため
の方策なのかと。（私見に過ぎませんが）

[Masayasu Ishikawa]

畑さん>

>モジュール化の結果、XHTML1.1では、XHTML1.0 Strict的なモジュール
>群を必須のコア・モジュールとし、それ以外のものは拡張モジュール
>として定義されるということですよね。（＞石川センセイ）

「コア・モジュール」という用語は "Modularization of XHTML" で
定義されてる [2] のでそういう使い方をすると誤解を招きますが、
まぁ大枠としてはさほど間違ってはいません。

>つまり、コアモジュールというのは吉○屋の牛丼で、フレームは、牛
>丼に対するオプションのお新香なわけで、お新香が吉○屋（W3C）の
>メニューから消えるということを意味するのではなくて、従来は、紅
>生姜みたいな扱いだったフレームモジュールが、将来的にはお新香の
>ように追加オプションとしてのメニューに変更になるよ、ということ
>ではないかと。

そこはちょっと違います。

[2] http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#sec_5.2.

--
Masayasu Ishikawa

# Death and Rebirth

[Masayasu Ishikawa]

ちょっと長くなりますが…。

畑さん>

>ただ、rubyタグに関しては、「地の文にタグをぶら下げる」
>という感覚から逸脱しているとは思います。ルビはあくまで
>もルビで、本文の飾りに過ぎないのに、

ルビの様々な用例を調べてみれば、ルビが単なる「飾り」ではなくむしろ
親文字列よりルビの方が重要な例はいくらでもあります。一般的な読みを
示す例で考えても、音声出力する場合は親文字列よりルビ文字列の方が
重要でしょう。

>rubyって、本文をぐ
>しゃぐしゃにしないと成立しませんし……。dlタグっぽい方
>式を採用しちゃったみたいで。
>
># むしろ、titleやaltみたいな、属性で指定する方が自然だ
># と思うのは僕だけでしょうか？
># ex. <ruby title="としのみやあいこ">敬宮愛子</ruby>

実際最初に Internet Draft として提案されたもの [3] は属性で指定して
いました。それがそのまま採用されなかったのにはそれなりに理由があります。

これは XML のボキャブラリを設計するときに常に問題となる、「ある情報
項目を表現する際に要素内容とすべきか、属性を用いるべきか」という点に
帰着します。それぞれメリット・デメリットがありますが、構造を持ち得る
データや属性を指定する必要のあるデータを表現する際は要素内容とすべき
です。例えば以下のような文章があったとします (説明のため属性を冗長に
指定してあります)。

<p xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" dir="ltr">
ヘブライ語の<ruby><rb xml:lang="he" dir="rtl">&#x05D0;&#x05D3;&#x05DD;</rb>
<rt xml:lang="ja" dir="ltr">アーダーム</rt></ruby>は「人間」を意味し、…
</p>

この例では親文字列がヘブライ語でルビ文字列は日本語です。外国語の
教科書などでは単語の読みを示すためにこのように親文字列とルビ文字列
の言語が異なることは珍しくありませんが、この例では書字方向まで異なり
ます。ルビを単なる属性としてしまうとルビ文字列が親文字列とは異なる
言語や書字方向である場合に困ったことになります。

またルビ文字列中に複数の言語が混在する場合もあり得ます。属性値を
マークアップすることはできませんから、この場合も属性にすると困った
ことになります。要素にしておけば例えば span 要素の xml:lang 属性を
使ってルビ文字列中の言語の変化を指定することができます。

総じて、国際化の観点からはテキストデータを表現する際には属性でなく
要素内容とすべき、というのが望ましい方針です。(X)HTML の img 要素
の代替文字列は alt 属性で指定するようになっていたのに対し、SVG の
グラフィクスに対する代替文字列は title 要素や desc 要素といった子
要素で指定するようになっているのもこのあたりが理由と言っていいで
しょう。このあたりのボキャブラリ設計に関する話は IDG から出ている
ムック『XML World』保存版第1弾に収録されている檜山正幸氏の「XML
ボキャブラリ作成のポイントを知る」という記事にまさにルビを例に挙げて
詳しく説明されているので興味があれば読んでみるとよろしいかと。

もう一つ忘れてはならないのは Ruby Annotation [4] という仕様はあくまで
XML を前提とした仕様であって、仕様書にもしつこいくらい書いてあるように
レンダリングはスタイルシートでコントロールすることになっています。で、
スタイルシートを適用するには属性よりも要素の方がはるかに柔軟性があり
ます。詳細にルビのスタイル指定を行なうには "CSS3 module: Ruby" [5] の
実装を待たねばなりませんが、Piro 氏の "ContextMenu-Extensions for
Netscape 6 & Mozilla" [6] のように CSS2 のテーブルモデルをうまく応用
して疑似的にルビのレンダリングを実現したものもあります。もしルビが
属性として定義されていたら、こういった形で対応することはかなり困難
でしょう。

私個人としては現在の Ruby Annotation のデザインに必ずしも満足して
いるわけではありませんが、そこに至ったのはマークアップ言語設計や
組版、国際化、アクセシビリティなどの専門家が意見を寄せ合って数年に
渡り検討した結果であって理由なしに「本文をぐしゃぐしゃにする」
デザインに落ち着いたわけではありません。

[3] http://www.w3.org/International/draft-duerst-ruby-01
[4] http://www.w3.org/TR/ruby/
[5] http://www.w3.org/TR/css3-ruby/
[6] http://www.cc-net.or.jp/~piro/works/_moz-extensions.html

--
Masayasu Ishikawa

# 「船頭多くして…」の典型例と言う話もある。

[Shinji KONO]

河野 真治@琉球大情報工学です。

In article <a3f3cd$qkt$1...@news.sfc.keio.ac.jp>,
mim...@sfc.keio.ac.jp (Masayasu Ishikawa) writes

>これは XML のボキャブラリを設計するときに常に問題となる、「ある情報
>項目を表現する際に要素内容とすべきか、属性を用いるべきか」という点に
>帰着します。

一般的に、データの表現をオジェクトレベル/メタレベル、あるい
は、要素/属性のように階層構造にした時には、その階層構造は一
意に定まりません。どのようなわけかたをしても「これには都合が
悪い」とかいうのが出て来るわけ。

これには理論的な理由があると思う。要は「階層構造が満たす要求
仕様の完全性」にあるわけなんだけど、表現すべきデータの構造が、
それ自身、メタ階層構造を持つようなものだと、要求仕様に自己参
照的な矛盾がでてしまうのだと思います。

解決するには、未定義要素みたいなものを導入して表現できる階層
構造を無限の階層構造にするとか、表現を多態的にするとかが多い
んじゃないかな。オブジェクト指向設計屋さんが歩んで来た道だ....

とかいっても、なんの役にも立たないんだけど。全然関係ないこと
言っているとか思われても、そうですねとしか言えなかったりする。
でも、哲学や基礎数学を知らない奴に、述語論理的な仕様記述をや
らせるべきではないのかもね。

> <p xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" dir="ltr">
> ヘブライ語の<ruby><rb xml:lang="he" dir="rtl">&#x05D0;&#x05D3;&#x05DD;</rb>
> <rt xml:lang="ja" dir="ltr">アーダーム</rt></ruby>は「人間」を意味し、…
> </p>
>この例では親文字列がヘブライ語でルビ文字列は日本語です。外国語の
>教科書などでは単語の読みを示すためにこのように親文字列とルビ文字列
>の言語が異なることは珍しくありませんが、この例では書字方向まで異なり
>ます。ルビを単なる属性としてしまうとルビ文字列が親文字列とは異なる
>言語や書字方向である場合に困ったことになります。

でも、属性で書いた方が見やすいって言う人がいるなら、そうして
あげたいですよね...

[ka...@sra-tohoku.co.jp]

>> # 「船頭多くして…」の典型例と言う話もある。

XML屋的にはどうだか判りませんけど、
SGML的には「地の文として見えて欲しいものは内容とする」の原則に
沿っているので、現状のrubyは妥当であるとは思います。
＃どっちを先に書くべきかて問題は残りますが
ので

<14300.10...@insigna.ie.u-ryukyu.ac.jp>の記事において
ko...@ie.u-ryukyu.ac.jpさんは書きました。
>> でも、属性で書いた方が見やすいって言う人がいるなら、そうして
>> あげたいですよね...
そりゃ単に原則がわかってないだけです。
--
kabe

[Masanori HATA]

畑です。

"Masayasu Ishikawa" <mim...@sfc.keio.ac.jp> wrote in message news:a3f3cd$qkt$1...@news.sfc.keio.ac.jp...

> >ただ、rubyタグに関しては、「地の文にタグをぶら下げる」
> >という感覚から逸脱しているとは思います。ルビはあくまで
> >もルビで、本文の飾りに過ぎないのに、
>
> ルビの様々な用例を調べてみれば、ルビが単なる「飾り」ではなくむしろ
> 親文字列よりルビの方が重要な例はいくらでもあります。一般的な読みを
> 示す例で考えても、音声出力する場合は親文字列よりルビ文字列の方が
> 重要でしょう。

これは、言われてみれば確かにそうですね。
言語を、視覚言語（文字表記）を、音声言語に対する副次的な表記用言語と
して捉えた時、そちらの方が自然だと思います。非漢字文化圏では、それが
あたりまえなんでしょうけど。

漢字という高度な抽象化表意表記言語を持っていると、表記言語が、音声に
対する副次的なものに留まりきれないのが、問題を生む原因なのかも知れま
せん。

# 全文かな（カナ）の表音文字だけで地の文章を書いて、漢字にしたい部分
# だけ、
# <china alt="敬宮愛子">としのみやあいこ</china>
# とするのが、音声言語的発想からは妥当かも？

「文章を文字として書く」ということを中心に捉えた場合のルビと、扱いが
違ってしまいますね。

# 「ルビ」と「よみがな」を分けて別々の要素にしてしまえば……
# リクエストばっかり (^^;

> >rubyって、本文をぐ
> >しゃぐしゃにしないと成立しませんし……。dlタグっぽい方
> >式を採用しちゃったみたいで。
> >
> ># むしろ、titleやaltみたいな、属性で指定する方が自然だ
> ># と思うのは僕だけでしょうか？
> ># ex. <ruby title="としのみやあいこ">敬宮愛子</ruby>

略

> これは XML のボキャブラリを設計するときに常に問題となる、「ある情報
> 項目を表現する際に要素内容とすべきか、属性を用いるべきか」という点に
> 帰着します。それぞれメリット・デメリットがありますが、構造を持ち得る
> データや属性を指定する必要のあるデータを表現する際は要素内容とすべき
> です。例えば以下のような文章があったとします (説明のため属性を冗長に
> 指定してあります)。
>
> <p xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" dir="ltr">
> ヘブライ語の<ruby><rb xml:lang="he" dir="rtl">&#x05D0;&#x05D3;&#x05DD;</rb>
> <rt xml:lang="ja" dir="ltr">アーダーム</rt></ruby>は「人間」を意味し、…
> </p>
>
> この例では親文字列がヘブライ語でルビ文字列は日本語です。外国語の
> 教科書などでは単語の読みを示すためにこのように親文字列とルビ文字列
> の言語が異なることは珍しくありませんが、この例では書字方向まで異なり
> ます。ルビを単なる属性としてしまうとルビ文字列が親文字列とは異なる
> 言語や書字方向である場合に困ったことになります。

略

> もう一つ忘れてはならないのは Ruby Annotation [4] という仕様はあくまで
> XML を前提とした仕様であって、仕様書にもしつこいくらい書いてあるように
> レンダリングはスタイルシートでコントロールすることになっています。で、
> スタイルシートを適用するには属性よりも要素の方がはるかに柔軟性があり
> ます。詳細にルビのスタイル指定を行なうには "CSS3 module: Ruby" [5] の
> 実装を待たねばなりませんが、Piro 氏の "ContextMenu-Extensions for
> Netscape 6 & Mozilla" [6] のように CSS2 のテーブルモデルをうまく応用
> して疑似的にルビのレンダリングを実現したものもあります。もしルビが
> 属性として定義されていたら、こういった形で対応することはかなり困難
> でしょう。

略

> 私個人としては現在の Ruby Annotation のデザインに必ずしも満足して
> いるわけではありませんが、そこに至ったのはマークアップ言語設計や
> 組版、国際化、アクセシビリティなどの専門家が意見を寄せ合って数年に
> 渡り検討した結果であって理由なしに「本文をぐしゃぐしゃにする」
> デザインに落ち着いたわけではありません。

略
> # 「船頭多くして…」の典型例と言う話もある。

つまり、色々な観点からの要望を付き合わせた上での、相対的なベスト
として、今の仕様に落ち着いたというわけなのですね。そこまで、考え
は到りませんでした。

本来的には、ローカルな拡張モジュールとして、日本語向けのAnother
なルビ用の要素を日本人たちで作って使うという方向で扱うべき問題な
のでしょうかね……。

[Masayasu Ishikawa]

畑さん>

># 「ルビ」と「よみがな」を分けて別々の要素にしてしまえば……
># リクエストばっかり (^^;

実際そういう意見もありました。しかしマークアップ言語設計の経験上、
詳細にマークアップできるようにしようと言語仕様を精緻化していけば
いくほどユーザはどの場合にどれを使ったら良いのかわからなくなり
かえって誤用が増えるという皮肉な結果になることが知られています。
現状の (X)HTML でも多すぎるくらいです。ルビの場合も様々な用例を
検討すれば「ルビ」と「よみがな」なんて簡単に分けて済むような問題
ではなく泥沼にはまり込むことが明らかだったため、あくまで親文字列
とルビ文字列という構造のみを記述してその意味論には踏み込まない
仕様に落ち着いています。

>つまり、色々な観点からの要望を付き合わせた上での、相対的なベスト
>として、今の仕様に落ち着いたというわけなのですね。そこまで、考え
>は到りませんでした。
>
>本来的には、ローカルな拡張モジュールとして、日本語向けのAnother
>なルビ用の要素を日本人たちで作って使うという方向で扱うべき問題な
>のでしょうかね……。

畑さんは「日本語向けのAnotherなルビ用の要素」なるものに具体的には
何をお望みなんでしょうか。Ruby Annotation の仕様が当初のドラフト
より複雑になったのは間違いなく日本語向けの要求を満たすためで、長い
協調作業の末に JIS X 4052 でも同一のモデルが採用されています。

# rp なんて「盲腸」はありませんけど。

現状の Ruby Annotation の仕様が唯一絶対などとは決して思いませんが、
車輪を再発明するコストに見合うだけのメリットがあるようには思えない
のですが。

--
Masayasu Ishikawa

# DTD モジュールの過剰な隠しオプションを眺めて笑うのが通の楽しみ方。

[Masanori HATA]

畑です。返事が遅れてすみません。

"Masayasu Ishikawa" <mim...@sfc.keio.ac.jp> wrote in message news:a3mdhv$kt7$1...@news.sfc.keio.ac.jp...

> ># 「ルビ」と「よみがな」を分けて別々の要素にしてしまえば……
>

> 実際そういう意見もありました。しかしマークアップ言語設計の経験上、
> 詳細にマークアップできるようにしようと言語仕様を精緻化していけば
> いくほどユーザはどの場合にどれを使ったら良いのかわからなくなり
> かえって誤用が増えるという皮肉な結果になることが知られています。
> 現状の (X)HTML でも多すぎるくらいです。ルビの場合も様々な用例を
> 検討すれば「ルビ」と「よみがな」なんて簡単に分けて済むような問題
> ではなく泥沼にはまり込むことが明らかだったため、あくまで親文字列
> とルビ文字列という構造のみを記述してその意味論には踏み込まない
> 仕様に落ち着いています。

> >本来的には、ローカルな拡張モジュールとして、日本語向けのAnother

> >なルビ用の要素を日本人たちで作って使うという方向で扱うべき問題な
> >のでしょうかね……。
>
> 畑さんは「日本語向けのAnotherなルビ用の要素」なるものに具体的には
> 何をお望みなんでしょうか。Ruby Annotation の仕様が当初のドラフト
> より複雑になったのは間違いなく日本語向けの要求を満たすためで、長い
> 協調作業の末に JIS X 4052 でも同一のモデルが採用されています。

うーん、そうですね……。「地の文に対するオマケ的要素」としてのルビ記
述ということになると思います。
先に、タグなどをなしに、ベタのplain textな状態で文章を記述し、その後
から、その地の文にタグを挿入していくようなやり方で、ルビの記述を可能
にはできなかったのかな、ということです。
表や、リストのようなものは、元々、表やリストを作成しようとして書くも
のだと思いますから、先に文章構造（箱）ありき、でもOKだと思うのです。
それに対して、通常の文章の場合は、先に無地の文章があって、その構造を
明示的に示すためにタグを挿入しているという感じだと、自然な感じがしま
す。<p></p>、<br />、<img />、<em></em>、<strong></strong>、
<span></span>といったものは、地の文に後から付け加えるだけで成立しま
すよね。ところが、<p>……</p>の内部に、
<ruby>
<rb>としのみや</rb>
<rt>敬宮</rt>
</ruby>
みたいな箱的な構造が入り込むことになるので、かなり、違和感を感じてし
まいます。一次元的なライン構造の中に、二次元的なブロック構造を押し込
んだみたいで……。あくまでも、インラインは一次元で統一されていれば、
違和感を感じずに済んだと思います。

日本語向けの要求を満たすために、複雑になってしまったというお話ですが、
ルビ的な記述に関する問題をインラインレベルと、ブロックレベルで分けて
扱うということは、さすがに、無理なのでしょうか……。
僕は決して、石川先生のように、色々な事情を知った上で発言しているわけ
ではありませんから、あくまでも広い観点から見て、僕の意見が妥当なもの
かは全くわかりません。ローカル・プライベートな意見でして。(^^;

[ka...@sra-tohoku.co.jp]

かべ＠ＳＲＡ東北

>> すよね。ところが、<p>……</p>の内部に、
>> <ruby>
>> <rb>としのみや</rb>
>> <rt>敬宮</rt>
>> </ruby>
>> みたいな箱的な構造が入り込むことになるので、かなり、違和感を感じてし
>> まいます。一次元的なライン構造の中に、二次元的なブロック構造を押し込
>> んだみたいで……。あくまでも、インラインは一次元で統一されていれば、

ルビってそもそも一次元的では *ない* ので、上のような箱構造は
すごく自然に思えるんですが…
だめすか？

音楽記述言語(日本でMMLて言われるやつ)で和音を記述するときに
みんな四苦八苦して記法を編み出しているのと似たような状況だというのを
いま思いつきました。

並列・並行プログラミング言語の記法も、本来箱形・二次元・同時的に書けた方が
いいものを、エディタなどの制約で無理やり一次元に書かねばならんので
分かりにくくなる、てのとも似ている、てのも今思いついたり。

[ku...@gssm.otsuka.tsukuba.ac.jp]

久野です。

ka...@sra-tohoku.co.jpさん:

> 並列・並行プログラミング言語の記法も、本来箱形・二次元・同時的

> に書けた方がいいものを、エディタなどの制約で無理やり一次元に書
> かねばならんので分かりにくくなる、てのとも似ている、てのも今思
> いついたり。

いちお、fj.comp.lang.miscに振りましょうか :-)

私は、箱型で2次元的に表現できる程度の並行性はわりとどうでもい
いような気がしています。もっともつれた場合を考えると、「1次元的
な記述言語」の方が結局使えたりするんじゃないか…

単なる予想ですけど。 久野

[Shinji KONO]

河野 真治@琉球大情報工学です。

In article <a44l0l$2n...@utogw.gssm.otsuka.tsukuba.ac.jp>,
ku...@gssm.otsuka.tsukuba.ac.jp writes

> 私は、箱型で2次元的に表現できる程度の並行性はわりとどうでもい
>いような気がしています。もっともつれた場合を考えると、「1次元的
>な記述言語」の方が結局使えたりするんじゃないか…

本来は、高次元立方体ですからね....

fp とか APL とかは1次元的かな? MPI とかも、そんな風に使っている
人が多いみたいですね。

配列を配って、
それをぞれを処理して、
次に、それを集めて、
また配列を配って...

[Masayasu Ishikawa]

今さらではありますが…。

私の記憶が確かならば、JST 時間2002年02月08日(金) 23時55分05秒頃、
fj.net.www.authoring の <a40os7$ruq$1...@news3.dti.ne.jp> の記事において
ha...@iname.com さんは書きました。

>> 畑さんは「日本語向けのAnotherなルビ用の要素」なるものに具体的には
>> 何をお望みなんでしょうか。Ruby Annotation の仕様が当初のドラフト
>> より複雑になったのは間違いなく日本語向けの要求を満たすためで、長い
>> 協調作業の末に JIS X 4052 でも同一のモデルが採用されています。
>
>うーん、そうですね……。「地の文に対するオマケ的要素」としてのルビ記
>述ということになると思います。

おそらくこの時点で Ruby Annotation という仕様とは相容れないと思います。
ルビを表現するには「オマケ」では済まないからこういう仕様になっている
のであって、「オマケ」でいいようなものはこの仕様の対象外でしょう。

>先に、タグなどをなしに、ベタのplain textな状態で文章を記述し、その後
>から、その地の文にタグを挿入していくようなやり方で、ルビの記述を可能
>にはできなかったのかな、ということです。

要は属性で書きたいということのようですが、本当にオマケ程度でいいなら
(X)HTML では各要素の title 属性で簡単な注釈を記述できますがそれでは
足りないんでしょうか。属性で指定することの問題点はすでに指摘した通り
です。

>ところが、<p>……</p>の内部に、
><ruby>
> <rb>としのみや</rb>
> <rt>敬宮</rt>
></ruby>
>みたいな箱的な構造が入り込むことになるので、かなり、違和感を感じてし
>まいます。一次元的なライン構造の中に、二次元的なブロック構造を押し込
>んだみたいで……。あくまでも、インラインは一次元で統一されていれば、
>違和感を感じずに済んだと思います。

これはかべさんのご指摘の通り、ルビはそもそも一次元ではありません。
(X)HTML では便宜上インライン・レベルに分類されていますが、敢えて言えば
ルビはインラインでもブロックでもなくインライン・ブロックです。CSS3 の
Ruby box model [7] あたりを見ればルビが通常のインラインの範疇を大きく
逸脱していることがわかると思います。だから CSS3 でも display プロパティ
の値が inline では足りず、わざわざルビ用の値が提案されています。

これをマークアップの側面から表現しようとすると、少なくとも

- 親文字列を表現する要素 (rb)
- ルビ文字列を表現する要素 (rt)
- 親文字列とルビ文字列をグルーピングする要素 (ruby)

あたりは必要になり、要素名の好みや親文字列とルビ文字列のどちらが先に
来るかなどを別にすれば構造としてはある意味これ以上簡単になりようが
ないと思います。無理矢理一次元で表現しようとするとそれこそ悪夢の
interlinear annotation characters (U+FFF9 - U+FFFB) みたいになって
しまいます。

>日本語向けの要求を満たすために、複雑になってしまったというお話ですが、
>ルビ的な記述に関する問題をインラインレベルと、ブロックレベルで分けて
>扱うということは、さすがに、無理なのでしょうか……。

前述のようにルビはインラインでもブロックでもないので「インラインレベル
とブロックレベルで分けて扱う」のは無理というより無意味です。

で、それでもどうしてもソースの可読性を気にするような人はよく使うルビ
は実体としてあらかじめ定義しておいて公開前に spam [8] でも使って展開
するとか、好きなように書いて XSLT で変換とかすればいいように思うん
ですが…。

おおもとの話に戻すと、OMITTAG だの SHORTTAG だのを駆使して手打ちの
数を減らして楽しようとするのが SGML 風なら、面倒なことは機械に処理
させて楽するのが XML 風だと思います。XHTML は SGML より XML の利点
の方を取ったわけですから、そちらの利点を活かして利用した方が幸せに
なれるのではないかと。

[7] http://www.w3.org/TR/css3-ruby/#box-model
[8] http://www.jclark.com/sp/spam.htm

--
Masayasu Ishikawa

# まぁ、text/xhtml+xml が総スカン食らって application/xhtml+xml になった
# のが XHTML の何たるかを端的に表してるような気がしないでもない。