目次 Edit


関連 Edit

検索:見解

見解周辺のタグ Edit

Array

見解とは Edit

ページリビジョン)の間にあるまとまり。
1ページに複数の見解があり、1つの見解に複数のがある。

(新規作成されたページには既に1つの見解と1つのが存在する)

また、章の実体はページなので、章ごとに見解があることになる。
読むときに見解代表が決まるので、「前章で述べたとおり…」と書いても、書いた人に見えている前章がみんなにも見えるとは限らない。

側面 Edit

側面、見られ方、立場、多態性、インターフェイスなどを表すための機能。
編集でいくつでも用意でき、参照する側が選択する。
どの側面でも共通する事柄は埋め込みリンクで。他の見解と共有。

事典では使わない。利用者ページでは特に有効。立場や役割別にページを用意できる。

調停 Edit

あるページ代表見解争いに負けても、他のページで勝利すればそれと整合させるために敗者復活があるかも知れない。
という考え方で諍い低減。

敗者復活のためには特定見解(の最新版)へのリンクが必要。特定見解を他のページで紹介。

制限無し Edit

編集制限はかけない。
どの派閥がどのページ編集しても良い。(Wikiだから)
そもそもお客様でも編集可能なのだから、利用者編集できなくしても無意味。

見解の相違 Edit

対立(編集合戦含む)を検出したら、分離するようおすすめする。
第三者が「こうしたらどうですか」的な例を作るのにも役立つ。

分離 Edit

fork
「分離する」という操作。自動ではない。おすすめするくらいなら可能。
分離は編集 + 投票
同じページ名の新しい記事を作り、それに支持票を入れる。元の記事には不支持票を入れる。

取り消し方法は…
→新しいページを消す。そのページは誰にも見えなくなる。

→分離は最新ではないを元に編集した場合に行なわれる?つまり改訂履歴の分岐。revertもその一例。
代表権は引き継がれないこと。分離したら代表は決め直し。→代表

統合 Edit

join/merge
「統合する」という操作。これも自動ではない。
ツールを提供する程度。手直しが必要でもいい。

統合には主従関係がある。
「主」が影響の少ない見解
「従」が吸収される見解
統合操作をした人が管理しているほうを主従関係の「従」ということにする。
同時に「主」と「従」に行なわれた投票結果も統合する。

新しい編集合戦 Edit

分離統合合戦が起きる。

影響 Edit

分離・統合があっても操作した人以外にはまったく影響なし。

機能で可能か Edit

見解は…

…だけなので機能化できる。

見解IDにページ名は含めないこと Edit

ページ名変更に対応しづらくなるので。
ページ内部名なら問題ない。

思い付き Edit

利用者が付けないほうが良い。
システムが自動的に無味乾燥で無意味で記号のような名前を付けるほうが良い。
0から始まる8進数とか。

見解/名前を付けるのにまた議論がいるようなことは無いほうが良い。

実装 Edit

名乗るなら見解ページにでも名前を書いておけばいい。
システムは関知しない。

システムが付けるIDは

  • 機能/ランダム文字列生成機能
  • 見解を表す接頭辞
    …の組み合わせで。

設計 Edit

見解ページ
見解IDは見解を表すページページ名になる。
属する利用者はこのページの中のリンクで表す。
リンク先は利用者を表すページ

記法/」で始まるページを作成

 
いろいろな記法
WikiCreole: List Of Wiki Markup
WikiMatrix - Compare them all

目次 Edit


関連 Edit

検索:記法

記法周辺のタグ Edit

Array

記法とは Edit

機能呼び出し記法シンタックスシュガー
呼び出す機能ごとに定義。1つの機能呼び出しについて複数記法を定義していい。

----
*
**
***
&(...);
#...

などのWiki特有の書き方のこと。
それと、これらの書き方で書かれたテキストのこと。
マークダウン」などと同じ用途・目的。→キーワード:Markdown Google:Markdown

WikiTextもWikiFormatも同じ意味で使われていそう。
ここでは記法を含むテキストをWikiTextと言うことにしている。

Google:Wiki-Notation
Google:Wiki-Format
Google:WikiText
Google:Wiki Formatted Text

実体は機能の呼び出し方(機能を呼び出したいときの書き方)。

→ X/Element/Notation[?]

思い付き Edit

Excel関数を参考に Edit

ページ見出しを、リンクする/されるの両方に Edit

ページ名を表す記法見出しを表す記法を用意。
段落始めに書けばページ名見出しを定義する。それ以外に書くと指定したページ見出しへのリンクになる。

タブでインデントしたい Edit

テキストエディターを使うとインデントしやすくなる。

見えない文字は無視したい Edit

使うとすれば記法を越えない程度に。
空白を取り除いても同じ記法になるように。

検索用クラスやめ Edit

検索」に書かれているクラスを廃止。
Notationクラスで行う。

Notationの機能…

  • 検索式→オブジェクトの単行表現
  • ページのテキスト→オブジェクトの複数行表現
  • オブジェクト同士を比較したときの適合度算出
    具象クラスが同じ場合も先祖が共通の場合も使える。
    先祖が共通の場合は適合度がやや下がる。
    クラスメソッド。
  • オブジェクト→テキスト(HTML)

…といったことができる。

機能は検索時の比較方法もメソッドとして持つ。 Edit

色とか。色機能(色を示す表現を色オブジェクトに置き換える機能)色を示す記法機能。

#FFF
White

…などが

#FFC

などと近く(高い適合率)になるように。

ヘルプは初心者向けのみ Edit

詳細な説明なら定義ページを見ればいい。

変換ルールはページ内で定義 Edit

記法→内部形式(Element系オブジェクト)のルール

RegExp→Element系クラス名

…という形式で定義。

1ページに1クラス分の複数書式を定義。ページ名と対応するクラスはハードコーディング(変更不可能)で良い。
それらをまとめたページを作れば記法定義の一覧になる。


でも、Notationを単なる 正規表現→機能名とパラメーター とすれば1ページにいくらでもまとめてもいいかも知れない。
例外がなければ。

Notation定義を参照するときのキーは?
特定ページ、または特定のページ以下にあるページ集合?

実装 Edit

埋め込み式ページ[?]を応用して実装。
記法を、「機能呼び出し記法が書かれたページ」を埋め込むことで実現できる。
そうすれば記法→機能呼び出しをページで定義・カスタマイズできる。

…というのはパラメーターなしの機能呼び出しだけ。
ほとんどのNotation記法/定義に書かないといけない。

色々な記法 Edit

  • 単行テキスト
  • 複数行テキスト
  • メールアドレス
  • URL
    http:、https:、ftp:のほかtwitter:なども。
  • 数値と計算式とフォーマット
    金額とか。
  • 日時と計算式
  • 時間(日時×2)と計算式
  • 選択・列挙
    文字列の列挙、列挙されていない値は持てない。選択可能数1または任意個。
  • ページ任意数
    とフィルタリングルール。フィルタリングで特定のページだけを選択肢に。ユーザー限定など。
    添付ファイル、添付イメージなどはページとして記述。

URL、ISBN、ASIN、電話番号、住所などを特別扱いに。

どこでも記法 Edit

特別なNotation Edit

機能ではないもの。特別扱いする必要のあるもの。

種別、影響範囲 Edit

WikiCreoleの実装にも適用。
影響範囲の小さい順に行修飾、文字修飾、段落…。
影響範囲が重なっている部分では、範囲の小さい記法が優先される。

以下、影響範囲の小さい順(優先度の高い順)

  1. 行修飾、ライン
    改行間の全てに影響。
    行頭に書く。行頭を含むNotation。1行にしか影響しないのは行頭に書くものなので。書き方の問題。
    **見出し
  2. 行修飾(連結)
    行頭。で次の行も同じNotationならまとまる。というよりも前の行が同じなら連結。(もし衝突があったとしても)前の行の属性が優先されるので。
    -リスト
    -リスト
  3. 文字修飾、インライン
    どこからでも開始できる。
    改行を越えて影響するため、行修飾よりも広範囲。
    //斜体//
  4. 段落修飾、パラグラフ
    空行(連続改行)間で有効。
    空行後に書く。というか、空行が無くてもこのNotationからを段落とみなす。
    少なくとも行頭に書く必要あり。このNotationだけで1行。というか改行を含むNotation
    >>
    引用(brockquote)
    <<
    末尾を<<で終わらせるようにすれば段落(空行)を越えられるが…→連結するなら、越えなくていい。
    >> ... <<で空行を越える記法はスクロール不要な長さなら影響範囲が分かりやすくなる。長い場合は段落ごとに>>を書いたほうが分かりやすい。
    斜体などの段落があってもいい。
  5. 段落修飾(連結)
    段落修飾は全て連結可能にしていいはず。ゆえに段落修飾はどれも連結する。でも毎段落ごとにNotationが必要になるので、<<で終了させる形のほうが書くときの手間がかからない。→<<で閉じる?
  6. ページ
    1ページ全体に影響。なので、どこに書いてもいいが専用欄を設けてもいい。
    ページ冒頭か末尾に書くのが簡単?
    ページ/属性にする

行頭後・空行後に書くものは改行処理前に解釈。それ以外は改行処理をした上で解釈。ただ空行は残すので空行後の物は改行処理の後でもいい。
改行→<br/>をする設定でもしない設定でも、文字修飾は改行を越える。空行も越えられるが…→WikiCreoleに合わせて越えないようにする。影響範囲が分かりやすい。

曖昧な記法を解釈 Edit

書き手の意図を反映させるように。
記号の前後は必ず何らかの効果が現れるように。

 **リスト
で、
 …**太字**
のとき、

 …**B**B**… → …<b>B</b>B**…
 **B**… →<b>B</b>… または <li>B**…
 **…**B**… → <li>…<b>B</b>…
 **B**…**B**… →<b>B</b>…<b>B</b>… または <li>B<b>…</b>B**…

正しくは
 ****B** → <li><b>B</b>

ユーザーが入力した情報が失われてしまうのを防ぐため、余ったNotationは消さずに残す。

bとして解釈できる場合、行頭の**を2つの意味で捉える?
 **B** →<li><b>B</b>
他のケースで使いにくく(結果を予想できなく)なってしまいそう。

設計 Edit

記法が含むもの Edit

  • 記法
    入れ子。
  • 機能呼び出し
    • 機能名と入力するデータ列
  • 機能呼び出し以外のマークアップ
    もしあれば。
    (これも結局機能として扱うので、結局機能と同じ)