WikiName
元祖のWikiでは、2つ以上の単語をmixed case (WikiName とか ThisIsAnotherWikiName ) で書いておくと、それが自動的に
Wiki内の他のページへのリンクになる。これをWikiNameと呼ぶ。
良いアイディアだと思うのだけれど、日本語では使えない。
日本語拡張されたWikiCloneでは特殊な区切り記号を用いて
WikiNameとしているものが多い。WiLiKiもそれにならった。
Mixed Caseの起源
mixed case を WikiName とする、というのはWikiが作られた
もともとの目的がJava,C++などでのプログラミングに関する議論の
場を作ろう、ということだったからのような気がします。
- 文中にほとんど現れない mixed case を利用して、特別な表記を
使わずに、リンクやその飛び先の新しいページを作るしくみを組み
込もうとした…という説もあります。Wiki には、HTML ソースの読みにくさ
に対するアンチテーゼが込められていて、ソースがそのまま読み下せる
というのも大きなメリットかと。--sumim
ああいった言語では識別子を命名するときにmixed caseを使う習慣が
あるんですよね。
- オリジナル Wiki の発案者で作者の Ward-Cunningham と彼に開発途上の
HyperCard を与えてそのきっかけを作った Kent-Beck は Smalltalker
としても知られています。--sumim
ですから逆に WiLiKiでは英小文字をハイフンでつないだものを
wiki-name? として自動認識させるようにしたら面白いのでは
ないかと思いました。
(単に面白いだけで実用性が無いのはあいかわらずですが‥‥‥)
- 確かに。元祖Wikiはデザインパターンの議論に使われていましたっけ。
ハイフンつなぎはLisp的というわけですね -- Shiro
- あとアンダーバー繋ぎをWikiNameと認識するWikiCloneも有っても良いような気がしています。快適かどうかは不明ですが。 -戯
MixedCaseの単語区切りを展開したら
Swiki にも WikiName はありませんので親近感?がありますw。--sumim
WikiClone って、WikiName をきちんと展開(ページのタイトルになった
とき、省略されたスペースを補完して Wiki Clone 、Wiki Name と表示)しない
ですね。なんか理由があるのでしょうか。--sumim
- スペースが省略されているとは限らない、からではないでしょうか?WikiNameを書いた人が何を期待してそのWikiNameを書いたかは「不明(=自由)」ですよね。また他人がそれをどう解釈するかも「不明(=自由)」だし。結局、書かれたものを解釈せずそのまま使うのが一番安全というか効率的というか合理的というか。解釈の余地は各自のハートの中にあれば十分かも。-戯
- それの限界が嫌(=不自由)だと思う人は、区切り記号によってWikiNameの自由度が増している、WiLiKiなど(^^;の拡張WikiEngineを使えばいいし。
- なるほど。で、改めてオリジナル Wiki を見てみると、英語表現においても、Wiki Name に関して
いろいろな制限があることが指摘され問題視された経緯があることが分かりました。
Wiki Name システムはクールだけど、多国語への対応や、英語自体においてもすでに問題が明確になっていて、
新しく Wiki Clone を作る際に、それを踏襲する必然性は損なわれている…との認識に至りました。--sumim
ページ名に空白を含めるには
WiLiKi:WishListより移動
- 2003/08/02 19:22:13 PDT:
pagenameにスペースを含める方法はありませんか?
Shiro (2003/08/18 01:43:16 PDT): src/wiliki/format.scmのreader-macro-wiki-name?
の4行目の(string-index-name #[\s]) でスペースの入っているページ名を
弾いているので、これを除けば多分できるんじゃないかと思います(試していません)。
そういうページ名を許すとどうなるかあまり深く考えてないので。
何か嬉しいことはありますか。
- (2003/08/28 19:38:25 PDT):
嬉しいこと…というか、不便に感じていないのでしょうか?
運用でカバーしてるから?
Shiro (2003/08/29 01:26:17 PDT): 多分、こんな理由で、私はpagenameに
空白を含めたいと思ったことがないのです:
- ページのタイトルは簡潔な方がわかりやすい
- ページのタイトルはページを同定するキーなので、
見た目で判別しにくい文字は入れたくない (例えば、「あ あ」というページと
「あ あ」というページと「あ あ 」というページが別々に出来たらあんまり
嬉しくない)。
- ページへのリンクとなる方の文章では、たまに長いフレーズから
リンクを張りたい場合があるが、それはむしろanchor文字列と
ページ名を別に指定できるようなメカニズムで解決されるべきでは
で、特に3番目の機構に関して、PageNameに空白が入らないことが分かっていれば
[[PageName アンカー文字列]]という文法が使えるなあ、と思っています。
- (2003/09/01 19:05:50 PDT): 私はページタイトルは内容を素直に表現するべきと思っています。
例えば common lisp についてのページには「common lisp」というタイトルを付け
たいです。
それと、2番目の理論などは、日本語だから成り立っているだけではありませんか?
Gauche: や Scheme: のプレフィクスで始まっているページ、例えば
「Gauche:ディレクトリを再帰的に処理」などは、日本語だからそういうページが
作れているけれども、これを英語にしようとすると現状の仕様では書けません。
それとも、他の一部のページで無理矢理採用しているような
「Gauche:ProcessDirectoryRecursively」こんな書き方にする、というルール
付けにして運用でカバーするのでしょうか?
- いや、2番目の理屈は英語でもありの話で、
スペースが1個と2個とかスペースではなくタブが入っているとかが別扱いになるとすると気持ち悪いという話でしょう。
その意味では英語だろうと日本語だろうと無関係で、この点は考慮する必要はあると思います。
ただ、私も Shiro さん同様あまり空白を入れたいと思いませんでしたが、
上記の wish 内容を読んでいると、日本語なら空白不要(元々日本語はそうだし)でも
英語タイトルでは使いたい(元々英語はそうだし)という要求も納得できますね。cut-sea:2003/09/01 22:18:25 PDT
- Shiro さんの言われる2番目の件に関して言うと、ページタイトルの読みこみ時に連続する
空白文字を1文字スペースへ圧縮してしまうのとタイトル末尾の空白文字は削除で逃げるという方法が安易だけど解その1かな。
タイトル文字列の意味的な唯一性を保つという意味ではそれで正しいと思います。
(lisp でシンボル名を case fold して同じ物扱いするのと似てるという意味でね。最近は違ってきてますでしょうが)
で、問題はこの空白の含め方でしょうね。
3の様に、タイトルとアンカーを別に定義するとなるとちょっと面倒な気もするなぁ。cut-sea:2003/09/01 22:18:25 PDT
Shiro (2003/09/01 23:01:48 PDT): なるほど。元々のWikiNameの発想が頭にあったので、
ProcessDirectoryRecursively の方が「オブジェクトとしてのページ」のID
という感じがするなあと思っていたのですが、そういう前提をとっぱらって
考えてみれば、ブラケット名を採用した時点でWikiName式の綴りを使う必要性は
無くなっているのですよね。紛らわしい名前に関しては、細かいことを言えば
ASCIIの空白以外にもいくつもあるので(現在でもいわゆる全角空白は入ってしまうはず)、
最終的には利用者に気を付けてもらうしかないし。
とりあえず、文字間の空白は許す(WikiNameの前後の空白や、空白だけの名前はダメ)
って感じで運用してみようかな。
- Shiro (2003/09/01 23:19:41 PDT): InterWikiNameとか、URL直書きの場合に
困りそうな気もしますね。%20とエスケープしても、システムの方で
%2520と直される可能性もあるし…まあ、現状でも特殊文字を使ったページ名は同様の
問題を持っているんで、あまり悩んでもしょうがないか。
bracket vs paren
- ふじさわ (2003/09/06 02:00:00 JST): ぼくらはせっかくSchemerなんだし(ほんとか?)、いっそのこと括弧で表現しませんか? たとえば、「(Location "AWikiName" (Location "AInterWikiname" self))」と、いくらでも入れ子で表現できるようにするとか(この延長線上には(Location "A" (Location "B" (Location "C" ... self)))なんてものが見えてきますよぅ)。ハイパーリンクもある面では多段の階層構造といえるわけで、こうすることでハイパーリンクの機能を補完/拡張できるんじゃないかなと思います。(実験的に弊WikiではそんなWikiNameを採用しています。もっとも、まだちゃんと動いてないですが)。
Shiro (2003/09/05 13:24:15 PDT): Wikiのような、通常の文章にディレクティブを埋め込む
文法の場合、「なるべく『地の文』と干渉しにくく、かつ、なるべく簡単な文字列」
を特別扱いする必要がありますね。ディレクティブが普通の文章にもよく出てくる
ような文字列だったらその文字列をエスケープすることに気を使わなくちゃならないし、
それを避けるためにあんまり複雑にしすぎても使うのが難しくなるだけ。
オリジナルのWikiNameは、(少なくとも英語圏では)そのへんのバランスがまあうまく
取れている解だったとは思います。(それでも干渉を防げないことがしばしばありますが)。
BracketNameもその精神にはわりと合致しているんじゃないかと。
Schemeの形式を取る場合、考慮すべきなのは次のような点かと。
- カッコは地の文にもよく出てくるので、どうやってディレクティブと区別するか?
- Wikiのように多くが文字列操作の場合、ディレクティブ中のリテラル文字列を
"..." で表現するのは繁雑に感じることがある。むしろ変数参照の方を特別扱いする、
sh系の文法の方が良くは無いか。
- 文法エラーがあった時に、Gracefulに対応できるか? 例えば1行目にカッコの閉じ忘れ
があり、最終行にカッコがひとつ余分だった時に、全てがひとつのカッコ無いの
ディレクティブだと判断されてしまうのは、あまり嬉しくない。
ディレクティブと地の文の区別
- ふじさわ まず、私のテスト実装では、括弧が出てきたら通常のS式と同じように「(関数 ...)」と扱うようにしました(区切り文字は、一応1つ以上のスペース文字です)。このとき、「関数」に該当する先頭要素の文字列(この例では「Location」)がシステムに登録されているならば、それを関数と見なし、括弧に囲まれた部分に何らかの加工を行います。登録されていない場合は、「普通の文字列」として扱います。とくに日本語を使うケースではスペース発生頻度が低いこともあり、これで問題が発生するケースは少ないと見積もっています。shiroさんが指摘されているように、特別扱いすべき文字列に適度な「複雑度バランス」を持たせることが重要だと考え、一応それなりの文法ルールにしたつもりです(もうちょっというと、私のテスト実装ではディレクティブ文法の特殊性を向上させるため、関数として「言及」や「情報源」などを登録しています)。ただし、英語圏に日本語圏と同じバランスを適用できないのがつらいところですね。英語圏についても、同様の文法ルールでそれほどバランスを崩さないのではないかと考えていますが、まだ深く考察できていないというのが正直なところです。あるいは英語圏では、複雑度を抑えながら文字列の特殊性を表現できる何らかの方法を適用すべきでしょうね。(たとえば英語圏でも漢字の関数名を採用してもらったら面白いかなとかも思いましたが、まあバランスは悪いかな。漢字自体表意文字なので可読性も維持でき、面白いと思うんですけどねぇ。)
- ちなみにオリジナルWikiNameのバランスについてですが、用途によってはもっといい最適解があるんじゃないか、実装によって表現の幅はもっと広くてもいいんじゃないかと思っています。たとえば「スペースを含むWikiNameを許してほしい」などの要求を持つ人は多いんじゃないでしょうか。公的な文章を扱う仕事では、人名であったり会社名であったりのスペースを厳密に扱いたいという要求があります。「Turbolinux」はスペースを含まないし「L」は小文字だとか、「Red Hat Linux 9」と表記しろだとか。
リテラル文字列の扱い
- ふじさわ すみません、sh系の文法というのがよく分かりませんでしたので、とりあえずこの観点は置いておきます。ディレクティブの発生頻度に着目すると、文書全体からすれば、それはかなり低い頻度で出現すると考えています。そういう状況で、「ディレクティブの中では"..."がネストしないように気をつかう」のはそれほど繁雑に感じないだろうと。まあ、何となく「"」使う文法っていやだなとは、きっとみな思うでしょうけどね。
Shiro: sh系の文法とは、通常の文字列トークンはリテラルとして扱い、
変数参照の場合にそれを明示する方法のことです(例: $PATH など)。
- ふじさわ つまり、こういうことですね。たとえばshでは「TERM=vt100」という文法を許す。これは実質的には"vt100"という文字列をTERMという変数に代入したことになる。つまり$TERMを評価すると"vt100"になると。で、この方式をWikiNameに適用すると……文法的には「Red Hat Linux 9」または「Red_Hat_Linux_9」をブラケット2つでくくったものをWikiNameとし、これを評価すると「Red Hat Linux 9」と表示するようにしようということですよね。うん、まあたしかに。「WikiNameにスペースを含みたい」という要求に応えるなら、これでいいんですよね。……私が論点をずらしてしまったのか。ごめんなさい。
文法エラーのgracefulな処理
- ふじさわ そうですね。これは難しい問題で、テスト実装では未解決です。(現状ユーザー数1名なので、運用で十分回避できています)。ただ、この問題はBracketNameでも同様に発生するはずですので、あまり気にしていません。あくまで自然文の拡張なので、それほど複雑な構造にしませんよねと。つまり、XMLのようなstrictさは目指していません。こう割り切っちゃってます。あいまいなタグの取り扱いへの対応は、それなりに難しい実装になるんでしょうが、ほかの領域の問題だと考えています。どうでしょうか。
gracefulな処理に関して言うと、行指向の文法は結構ロバストです。
一応、WiLiKiでは不正な入力が来たときでも「見えなくなる」ことはないように
しています。
- ふじさわ なるほど、ありがとうございます。では、ディレクティブに関しては、できるだけ行指向に処理するようインプリし直してみます。そのほかのテキスト整形ルールは、できるだけ階層構造になることを目指してるんですよ。当初目標は「S式Wiki」だったので。
階層構造にならない入力が来たときにどう処理するかですね。
最終更新 : 2012/03/18 11:16:14 UTC