記法 のバックアップの現在との差分(No.51)

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• バックアップ を表示
• 記法 へ行く。

---

目次 †

1. 目次
2. 関連
3. 見解周辺のタグ
4. 見解とは
   1. 記法
      1. 側面
      2. :i/記法定義は記法→要素クラス→記法
      3. :Done/記法定義の方法
      4. :i/ページの内容はコードと見なせる
   2. 調停
   3. 制限無し
      1. Markdownの特徴
   4. 見解の相違
   5. 分離
   6. 統合
   7. 新しい編集合戦
   8. 影響
   9. 機能で可能か
   10. 見解IDにページ名は含めないこと
5. 思い付き
6. 実装
7. 設計
   1. いろいろな記法
   2. 参考に
8. 目次
   1. 記法/
9. 関連
10. 記法周辺のタグ
11. 記法とは
12. 思い付き
    1. Excel関数を参考に
    2. ページと見出しを、リンクする/されるの両方に
    3. タブでインデントしたい
    4. 見えない文字は無視したい
    5. 検索用クラスやめ
    6. 機能は検索時の比較方法もメソッドとして持つ。
    7. ヘルプは初心者向けのみ
    8. 変換ルールはページ内で定義
13. 実装
    1. 色々な記法
    2. どこでも記法
    3. 特別なNotation
    4. 種別、影響範囲
    5. 曖昧な記法を解釈
14. 設計
    1. 記法が含むもの

• -
  記法案。それと記法の実装案。

関連 †

• 記法

• -----------------------------------------------

検索:見解
記法

見解周辺のタグ †

Array
記法定義は汎用記法のシンタックスシュガー。

• シンタックスシュガーは、記法のどの部分を汎用記法のどのパラメーターにするかを決める。
• シンタックスシュガーは、汎用記法のどのパラメーターをどんな値にするかを決める。

汎用記法は全ての要素を表現できる記法。要素クラス名をパラメーターとして受け取れる。

見解とは †

ToMarkdown()などを持つのはビルトイン要素。
プラグイン要素はそういった記法系に無い。汎用記法と、それにマッピングしたシンタックスシュガーでのみ表記できる。
ページと版（リビジョン）の間にあるまとまり。
1ページに複数の見解があり、1つの見解に複数の版がある。
（新規作成されたページには既に1つの見解と1つの版が存在する）

• -

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

1. 目次
2. 関連
3. 見解周辺のタグ
4. 見解とは
   1. 記法
      1. 側面
      2. :i/記法定義は記法→要素クラス→記法
      3. :Done/記法定義の方法
      4. :i/ページの内容はコードと見なせる
   2. 調停
   3. 制限無し
      1. Markdownの特徴
   4. 見解の相違
   5. 分離
   6. 統合
   7. 新しい編集合戦
   8. 影響
   9. 機能で可能か
   10. 見解IDにページ名は含めないこと
5. 思い付き
6. 実装
7. 設計
   1. いろいろな記法
   2. 参考に
8. 目次
   1. 記法/
9. 関連
10. 記法周辺のタグ
11. 記法とは
12. 思い付き
    1. Excel関数を参考に
    2. ページと見出しを、リンクする/されるの両方に
    3. タブでインデントしたい
    4. 見えない文字は無視したい
    5. 検索用クラスやめ
    6. 機能は検索時の比較方法もメソッドとして持つ。
    7. ヘルプは初心者向けのみ
    8. 変換ルールはページ内で定義
13. 実装
    1. 色々な記法
    2. どこでも記法
    3. 特別なNotation
    4. 種別、影響範囲
    5. 曖昧な記法を解釈
14. 設計
    1. 記法が含むもの

記法 †

記法は読むためのもの。書くためのものではない。

側面 †

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

:i/記法定義は記法→要素クラス→記法 †

:Done/記法定義の方法 †

:i/ページの内容はコードと見なせる †

記法はコードのようなもの。実行結果がページの閲覧時に組み込まれる。
他の言語のコードを書くのならシンタックスハイライトとか自動リンクとか。コンテンツ扱い。実行のようなことはしないで。
事典では使わない。利用者ページでは特に有効。立場や役割別にページを用意できる。

調停 †

あるページの代表見解争いに負けても、他のページで勝利すればそれと整合させるために敗者復活があるかも知れない。
という考え方で諍い低減。
敗者復活のためには特定見解（の最新版）へのリンクが必要。特定見解を他のページで紹介。

制限無し †

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

Markdownの特徴 †

http://space.hatena.ne.jp/pmint/entry/14218542507645637066

見解の相違 †

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

分離 †

fork
「分離する」という操作。自動ではない。おすすめするくらいなら可能。
分離は編集 + 投票。
同じページ名の新しい記事を作り、それに支持票を入れる。元の記事には不支持票を入れる。
取り消し方法は…
→新しいページを消す。そのページは誰にも見えなくなる。
→分離は最新ではない版を元に編集した場合に行なわれる？つまり改訂履歴の分岐。revertもその一例。
代表権は引き継がれないこと。分離したら代表は決め直し。→代表

統合 †

join/merge
「統合する」という操作。これも自動ではない。
ツールを提供する程度。手直しが必要でもいい。
統合には主従関係がある。
「主」が影響の少ない見解。
「従」が吸収される見解。
統合操作をした人が管理しているほうを主従関係の「従」ということにする。
同時に「主」と「従」に行なわれた投票結果も統合する。

新しい編集合戦 †

分離統合合戦が起きる。

影響 †

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

機能で可能か †

見解は…

• ページ作成
• 有力な見解（ページ名だけ指定されたときに表示するページ）を決める条件に介入

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

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

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

思い付き †

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

実装 †

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

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

設計 †

見解はページ。
見解IDは見解を表すページのページ名になる。
属する利用者はこのページの中のリンクで表す。
リンク先は利用者を表すページ。
「記法/」で始まるページを作成

記法/:

 

いろいろな記法

変換前/後が何であるか、何をどうするのかの違い。

いろいろな記法 †

• Markdown
  いろんな記法が混ざってる。普段使いの文章をフォーマットするための記法。日常の文章から見出された記法。
• WikiCreole
  各種Wikiの共通点。普段使いの文章と競合しないように選ばれてる。マークアップ言語。
• c2:TextFormattingRules
  オリジナル。
• pukiwiki:整形ルール
  PukiWikiの整形ルール。
• MediaWiki
  メジャー。
  WikiCreoleにも大きく影響してる。
  • -
• OwnNotation
  Xの独自記法。

参考に †

WikiCreole: List Of Wiki Markup
WikiMatrix - Compare them all
Help:Cheatsheet - Wikipedia, the free encyclopedia

目次 †

1. 目次
2. 関連
3. 見解周辺のタグ
4. 見解とは
   1. 記法
      1. 側面
      2. :i/記法定義は記法→要素クラス→記法
      3. :Done/記法定義の方法
      4. :i/ページの内容はコードと見なせる
   2. 調停
   3. 制限無し
      1. Markdownの特徴
   4. 見解の相違
   5. 分離
   6. 統合
   7. 新しい編集合戦
   8. 影響
   9. 機能で可能か
   10. 見解IDにページ名は含めないこと
5. 思い付き
6. 実装
7. 設計
   1. いろいろな記法
   2. 参考に
8. 目次
   1. 記法/
9. 関連
10. 記法周辺のタグ
11. 記法とは
12. 思い付き
    1. Excel関数を参考に
    2. ページと見出しを、リンクする/されるの両方に
    3. タブでインデントしたい
    4. 見えない文字は無視したい
    5. 検索用クラスやめ
    6. 機能は検索時の比較方法もメソッドとして持つ。
    7. ヘルプは初心者向けのみ
    8. 変換ルールはページ内で定義
13. 実装
    1. 色々な記法
    2. どこでも記法
    3. 特別なNotation
    4. 種別、影響範囲
    5. 曖昧な記法を解釈
14. 設計
    1. 記法が含むもの

• -

記法/ †

関連 †

検索:記法

記法周辺のタグ †

Array

記法とは †

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

----

*
**
***

&(...);
#...

などのWiki特有の書き方のこと。
それと、これらの書き方で書かれたテキストのこと。
「マークダウン」などと同じ用途・目的。→キーワード:Markdown Google:Markdown
WikiTextもWikiFormatも同じ意味で使われていそう。
ここでは記法を含むテキストをWikiTextと言うことにしている。
Google:Wiki-Notation
Google:Wiki-Format
Google:WikiText
Google:Wiki Formatted Text
実体は機能の呼び出し方（機能を呼び出したいときの書き方）。
→ X/Element/Notation[?]

思い付き †

Excel関数を参考に †

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

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

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

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

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

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

検索用クラスやめ †

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

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

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

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

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

#FFF
White

…などが

#FFC

などと近く（高い適合率）になるように。

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

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

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

記法→内部形式（Element系オブジェクト）のルール
RegExp→Element系クラス名
…という形式で定義。
1ページに1クラス分の複数書式を定義。ページ名と対応するクラスはハードコーディング（変更不可能）で良い。
それらをまとめたページを作れば記法定義の一覧になる。

• -

でも、Notationを単なる 正規表現→機能名とパラメーター とすれば1ページにいくらでもまとめてもいいかも知れない。
例外がなければ。
Notation定義を参照するときのキーは？
特定ページ、または特定のページ以下にあるページ集合？

実装 †

埋め込み式ページ[?]を応用して実装。
記法を、「機能呼び出し記法が書かれたページ」を埋め込むことで実現できる。
そうすれば記法→機能呼び出しをページで定義・カスタマイズできる。
…というのはパラメーターなしの機能呼び出しだけ。
ほとんどのNotationは記法/定義に書かないといけない。

色々な記法 †

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

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

どこでも記法 †

• 検索キーワードで
  計画に織り込み済み。
• ページ名として
  一行名がページ名なので。
  動的な記法が問題。ページ名が動的に変わっては不便。
  :t/？[?]
• ページ名変更時のページ名として
  ページ名変更UIによる。
  :t/？[?]

特別なNotation †

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

• リンク
  検索関連で特別扱い？
• 埋め込み（埋め込みリンク）
  埋め込み解消後のページをNotation解析対象にするので。
  Notationを埋め込みで実装するので？

種別、影響範囲 †

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

1. 行修飾、ライン
   改行間の全てに影響。
   行頭に書く。行頭を含むNotation。1行にしか影響しないのは行頭に書くものなので。書き方の問題。

   **見出し

2. 行修飾（連結）
   行頭。で次の行も同じNotationならまとまる。というよりも前の行が同じなら連結。（もし衝突があったとしても）前の行の属性が優先されるので。

   -リスト
   -リスト

3. 文字修飾、インライン
   どこからでも開始できる。
   改行を越えて影響するため、行修飾よりも広範囲。

   //斜体//

4. 段落修飾、パラグラフ
   空行（連続改行）間で有効。
   空行後に書く。というか、空行が無くてもこのNotationからを段落とみなす。
   少なくとも行頭に書く必要あり。このNotationだけで1行。というか改行を含むNotation。

   >>
   引用(brockquote)
   <<

   
   末尾を<<で終わらせるようにすれば段落（空行）を越えられるが…→連結するなら、越えなくていい。
   >> ... <<で空行を越える記法はスクロール不要な長さなら影響範囲が分かりやすくなる。長い場合は段落ごとに>>を書いたほうが分かりやすい。
   斜体などの段落版があってもいい。
5. 段落修飾（連結）
   段落修飾は全て連結可能にしていいはず。ゆえに段落修飾はどれも連結する。でも毎段落ごとにNotationが必要になるので、<<で終了させる形のほうが書くときの手間がかからない。→<<で閉じる？
6. ページ
   1ページ全体に影響。なので、どこに書いてもいいが専用欄を設けてもいい。
   ページ冒頭か末尾に書くのが簡単？
   →ページ/属性にする

• -------------------------------------

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

曖昧な記法を解釈 †

書き手の意図を反映させるように。
記号の前後は必ず何らかの効果が現れるように。
 **リスト
で、
 …**太字**
のとき、
 …**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>
他のケースで使いにくく（結果を予想できなく）なってしまいそう。

設計 †

記法が含むもの †

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